August 2023 - Linux-stable-mirror

[PATCH v1 1/9] media: qcom: camss: Fix pm_domain_on sequence in probe

by Bryan O'Donoghue

We need to make sure camss_configure_pd() happens before camss_register_entities() as the vfe_get() path relies on the pointer provided by camss_configure_pd(). Fix the ordering sequence in probe to ensure the pointers vfe_get() demands are present by the time camss_register_entities() runs. In order to facilitate backporting to stable kernels I've moved the configure_pd() call pretty early on the probe() function so that irrespective of the existence of the old error handling jump labels this patch should still apply to -next circa Aug 2023 to v5.13 inclusive. Fixes: 2f6f8af67203 ("media: camss: Refactor VFE power domain toggling") Cc: stable(a)vger.kernel.org Signed-off-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> --- drivers/media/platform/qcom/camss/camss.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c index f11dc59135a5a..75991d849b571 100644 --- a/drivers/media/platform/qcom/camss/camss.c +++ b/drivers/media/platform/qcom/camss/camss.c @@ -1619,6 +1619,12 @@ static int camss_probe(struct platform_device *pdev) if (ret < 0) goto err_cleanup; + ret = camss_configure_pd(camss); + if (ret < 0) { + dev_err(dev, "Failed to configure power domains: %d\n", ret); + goto err_cleanup; + } + ret = camss_init_subdevices(camss); if (ret < 0) goto err_cleanup; @@ -1678,12 +1684,6 @@ static int camss_probe(struct platform_device *pdev) } } - ret = camss_configure_pd(camss); - if (ret < 0) { - dev_err(dev, "Failed to configure power domains: %d\n", ret); - return ret; - } - pm_runtime_enable(dev); return 0; -- 2.41.0

1 year, 4 months

1
0
0 0

[PATCH AUTOSEL 5.10 1/3] idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM

by Sasha Levin

From: Baoquan He <bhe(a)redhat.com> [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: dmaengine(a)vger.kernel.org Link: https://lore.kernel.org/r/20230707135852.24292-2-bhe@redhat.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 08013345d1f24..7e1bd79fbee8f 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -208,6 +208,7 @@ config FSL_DMA config FSL_EDMA tristate "Freescale eDMA engine support" depends on OF + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help @@ -277,6 +278,7 @@ config IMX_SDMA config INTEL_IDMA64 tristate "Intel integrated DMA 64-bit support" + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help -- 2.40.1

1 year, 4 months

2
3
0 0

[PATCH net] net: stmmac: remove disable_irq() from ->ndo_poll_controller()

by Remi Pommarel

Using netconsole netpoll_poll_dev could be called from interrupt context, thus using disable_irq() would cause the following kernel warning with CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/irq/manage.c:137 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 10, name: ksoftirqd/0 CPU: 0 PID: 10 Comm: ksoftirqd/0 Tainted: G W 5.15.42-00075-g816b502b2298-dirty #117 Hardware name: aml (r1) (DT) Call trace: dump_backtrace+0x0/0x270 show_stack+0x14/0x20 dump_stack_lvl+0x8c/0xac dump_stack+0x18/0x30 ___might_sleep+0x150/0x194 __might_sleep+0x64/0xbc synchronize_irq+0x8c/0x150 disable_irq+0x2c/0x40 stmmac_poll_controller+0x140/0x1a0 netpoll_poll_dev+0x6c/0x220 netpoll_send_skb+0x308/0x390 netpoll_send_udp+0x418/0x760 write_msg+0x118/0x140 [netconsole] console_unlock+0x404/0x500 vprintk_emit+0x118/0x250 dev_vprintk_emit+0x19c/0x1cc dev_printk_emit+0x90/0xa8 __dev_printk+0x78/0x9c _dev_warn+0xa4/0xbc ath10k_warn+0xe8/0xf0 [ath10k_core] ath10k_htt_txrx_compl_task+0x790/0x7fc [ath10k_core] ath10k_pci_napi_poll+0x98/0x1f4 [ath10k_pci] __napi_poll+0x58/0x1f4 net_rx_action+0x504/0x590 _stext+0x1b8/0x418 run_ksoftirqd+0x74/0xa4 smpboot_thread_fn+0x210/0x3c0 kthread+0x1fc/0x210 ret_from_fork+0x10/0x20 Commit [0] introcuded disable_hardirq() to address this situation, so use it here to avoid above warning. [0] 02cea395866 ("genirq: Provide disable_hardirq()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Remi Pommarel <repk(a)triplefau.lt> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 4727f7be4f86..bbe509abc5dc 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -5958,8 +5958,8 @@ static void stmmac_poll_controller(struct net_device *dev) for (i = 0; i < priv->plat->tx_queues_to_use; i++) stmmac_msi_intr_tx(0, &priv->dma_conf.tx_queue[i]); } else { - disable_irq(dev->irq); - stmmac_interrupt(dev->irq, dev); + if (disable_hardirq(dev->irq)) + stmmac_interrupt(dev->irq, dev); enable_irq(dev->irq); } } -- 2.40.0

1 year, 4 months

2
2
0 0

From Anita.

by Fred Fedir k.

Hello I need your services in a confidential matter regarding fund. I have all the details relating to the funds. Please get back to me through my email with your response if you are willing to work with me. Best regards. Anita Anderson anitaanderson1122(a)proton.me

1 year, 4 months

1
0
0 0

[PATCH v3] usb: typec: tcpci: clear the fault status bit

by Fabio Estevam

From: Marco Felsch <m.felsch(a)pengutronix.de> According the "USB Type-C Port Controller Interface Specification v2.0" the TCPC sets the fault status register bit-7 (AllRegistersResetToDefault) once the registers have been reset to their default values. This triggers an alert(-irq) on PTN5110 devices albeit we do mask the fault-irq, which may cause a kernel hang. Fix this generically by writing a one to the corresponding bit-7. Cc: stable(a)vger.kernel.org Fixes: 74e656d6b055 ("staging: typec: Type-C Port Controller Interface driver (tcpci)") Reported-by: Angus Ainslie (Purism) <angus(a)akkea.ca> Closes: https://lore.kernel.org/all/20190508002749.14816-2-angus@akkea.ca/ Reported-by: Christian Bach <christian.bach(a)scs.ch> Closes: https://lore.kernel.org/regressions/ZR0P278MB07737E5F1D48632897D51AC3EB329@… Signed-off-by: Marco Felsch <m.felsch(a)pengutronix.de> Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v2: - Submitted it as a standalone patch. - Explain that it may cause a kernel hang. - Fixed typos in the commit log. (Guenter) - Check the tcpci_write16() return value. (Guenter) - Write to TCPC_FAULT_STATUS unconditionally. (Guenter) - Added Fixes, Reported-by and Closes tags. - CCed stable drivers/usb/typec/tcpm/tcpci.c | 4 ++++ include/linux/usb/tcpci.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c index fc708c289a73..0ee3e6e29bb1 100644 --- a/drivers/usb/typec/tcpm/tcpci.c +++ b/drivers/usb/typec/tcpm/tcpci.c @@ -602,6 +602,10 @@ static int tcpci_init(struct tcpc_dev *tcpc) if (time_after(jiffies, timeout)) return -ETIMEDOUT; + ret = tcpci_write16(tcpci, TCPC_FAULT_STATUS, TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT); + if (ret < 0) + return ret; + /* Handle vendor init */ if (tcpci->data->init) { ret = tcpci->data->init(tcpci, tcpci->data); diff --git a/include/linux/usb/tcpci.h b/include/linux/usb/tcpci.h index 85e95a3251d3..83376473ac76 100644 --- a/include/linux/usb/tcpci.h +++ b/include/linux/usb/tcpci.h @@ -103,6 +103,7 @@ #define TCPC_POWER_STATUS_SINKING_VBUS BIT(0) #define TCPC_FAULT_STATUS 0x1f +#define TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT BIT(7) #define TCPC_ALERT_EXTENDED 0x21 -- 2.34.1

1 year, 4 months

4
3
0 0

[PATCH] drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper()

by Lukasz Majczak

Check mgr->mst_primary, before passing it to the get_mst_branch_device_by_guid_helper(), otherwise NULL dereference may occur in the call to memcpy() and cause: [12579.365869] BUG: kernel NULL pointer dereference, address: 0000000000000049 [12579.365878] #PF: supervisor read access in kernel mode [12579.365880] #PF: error_code(0x0000) - not-present page [12579.365882] PGD 0 P4D 0 [12579.365887] Oops: 0000 [#1] PREEMPT SMP NOPTI ... [12579.365895] Workqueue: events_long drm_dp_mst_up_req_work [12579.365899] RIP: 0010:memcmp+0xb/0x29 [12579.365921] Call Trace: [12579.365927] get_mst_branch_device_by_guid_helper+0x22/0x64 [12579.365930] drm_dp_mst_up_req_work+0x137/0x416 [12579.365933] process_one_work+0x1d0/0x419 [12579.365935] worker_thread+0x11a/0x289 [12579.365938] kthread+0x13e/0x14f [12579.365941] ? process_one_work+0x419/0x419 [12579.365943] ? kthread_blkcg+0x31/0x31 [12579.365946] ret_from_fork+0x1f/0x30 Similar check is done in e.g: drm_dp_mst_topology_get_mstb_validated(). Fixes: 5e93b8208d3c ("drm/dp/mst: move GUID storage from mgr, port to only mst branch") Cc: <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Lukasz Majczak <lma(a)semihalf.com> --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index ed96cfcfa304..703cd97b1d11 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -2595,19 +2595,19 @@ static struct drm_dp_mst_branch * drm_dp_get_mst_branch_device_by_guid(struct drm_dp_mst_topology_mgr *mgr, const uint8_t *guid) { - struct drm_dp_mst_branch *mstb; + struct drm_dp_mst_branch *mstb = NULL; int ret; /* find the port by iterating down */ mutex_lock(&mgr->lock); - - mstb = get_mst_branch_device_by_guid_helper(mgr->mst_primary, guid); - if (mstb) { - ret = drm_dp_mst_topology_try_get_mstb(mstb); - if (!ret) - mstb = NULL; + if (mgr->mst_primary) { + mstb = get_mst_branch_device_by_guid_helper(mgr->mst_primary, guid); + if (mstb) { + ret = drm_dp_mst_topology_try_get_mstb(mstb); + if (!ret) + mstb = NULL; + } } - mutex_unlock(&mgr->lock); return mstb; } -- 2.41.0.640.ga95def55d0-goog

1 year, 4 months

2
2
0 0

[PATCH v2] pinctrl: cherryview: fix address_space_handler() argument

by Raag Jadav

First argument of acpi_*_address_space_handler() APIs is acpi_handle of the device, which is incorrectly passed in driver ->remove() path here. Fix it by passing the appropriate argument and while at it, make both API calls consistent using ACPI_HANDLE(). Fixes: a0b028597d59 ("pinctrl: cherryview: Add support for GMMR GPIO opregion") Cc: stable(a)vger.kernel.org Signed-off-by: Raag Jadav <raag.jadav(a)intel.com> --- Changes since v1: - Update subject and commit message drivers/pinctrl/intel/pinctrl-cherryview.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c index 7ffe4dafeebb..2bb574cf01d9 100644 --- a/drivers/pinctrl/intel/pinctrl-cherryview.c +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c @@ -1650,7 +1650,6 @@ static int chv_pinctrl_probe(struct platform_device *pdev) struct intel_community_context *cctx; struct intel_community *community; struct device *dev = &pdev->dev; - struct acpi_device *adev = ACPI_COMPANION(dev); struct intel_pinctrl *pctrl; acpi_status status; unsigned int i; @@ -1718,7 +1717,7 @@ static int chv_pinctrl_probe(struct platform_device *pdev) if (ret) return ret; - status = acpi_install_address_space_handler(adev->handle, + status = acpi_install_address_space_handler(ACPI_HANDLE(dev), community->acpi_space_id, chv_pinctrl_mmio_access_handler, NULL, pctrl); @@ -1735,7 +1734,7 @@ static int chv_pinctrl_remove(struct platform_device *pdev) struct intel_pinctrl *pctrl = platform_get_drvdata(pdev); const struct intel_community *community = &pctrl->communities[0]; - acpi_remove_address_space_handler(ACPI_COMPANION(&pdev->dev), + acpi_remove_address_space_handler(ACPI_HANDLE(&pdev->dev), community->acpi_space_id, chv_pinctrl_mmio_access_handler); -- 2.17.1

1 year, 4 months

3
2
0 0

[PATCH AUTOSEL 4.14 1/2] idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM

by Sasha Levin

From: Baoquan He <bhe(a)redhat.com> [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: dmaengine(a)vger.kernel.org Link: https://lore.kernel.org/r/20230707135852.24292-2-bhe@redhat.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 5ea37d133f241..6abb80b09db3b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -209,6 +209,7 @@ config FSL_DMA config FSL_EDMA tristate "Freescale eDMA engine support" depends on OF + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help @@ -254,6 +255,7 @@ config IMX_SDMA config INTEL_IDMA64 tristate "Intel integrated DMA 64-bit support" + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help -- 2.40.1

1 year, 4 months

1
1
0 0

[PATCH AUTOSEL 4.19 1/2] idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM

by Sasha Levin

From: Baoquan He <bhe(a)redhat.com> [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: dmaengine(a)vger.kernel.org Link: https://lore.kernel.org/r/20230707135852.24292-2-bhe@redhat.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e5f31af65aabf..00e1ffa4fcf1c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -212,6 +212,7 @@ config FSL_DMA config FSL_EDMA tristate "Freescale eDMA engine support" depends on OF + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help @@ -258,6 +259,7 @@ config IMX_SDMA config INTEL_IDMA64 tristate "Intel integrated DMA 64-bit support" + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help -- 2.40.1

1 year, 4 months

1
1
0 0

[PATCH AUTOSEL 5.4 1/2] idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM

by Sasha Levin

From: Baoquan He <bhe(a)redhat.com> [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/ Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Vinod Koul <vkoul(a)kernel.org> Cc: dmaengine(a)vger.kernel.org Link: https://lore.kernel.org/r/20230707135852.24292-2-bhe@redhat.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/dma/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 1322461f1f3c5..66aad9dbd58c5 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -208,6 +208,7 @@ config FSL_DMA config FSL_EDMA tristate "Freescale eDMA engine support" depends on OF + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help @@ -268,6 +269,7 @@ config IMX_SDMA config INTEL_IDMA64 tristate "Intel integrated DMA 64-bit support" + depends on HAS_IOMEM select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help -- 2.40.1

1 year, 4 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2023