May 2024 - Linux-stable-mirror

[PATCH v3 1/2] PCI: shpchp: Abort hot-plug if pci_hp_add_bridge() fails

by Nam Cao

If a bridge is hot-added without any bus number available for its downstream bus, pci_hp_add_bridge() will fail. However, the driver proceeds regardless, and the kernel crashes. This crash can be reproduced with the QEMU command: qemu-system-x86_64 -machine pc-q35-2.10 \ -kernel bzImage \ -drive "file=img,format=raw" \ -m 2048 -smp 2 -enable-kvm \ -append "console=ttyS0 root=/dev/sda" \ -nographic \ -device pcie-root-port,bus=pcie.0,id=rp1,slot=1,bus-reserve=0 \ -device pcie-pci-bridge,id=br1,bus=rp1 then hot-plug a bridge at runtime with the QEMU command: device_add pci-bridge,id=br2,bus=br1,chassis_nr=1,addr=1 and the kernel crashes: shpchp 0000:01:00.0: Latch close on Slot(1-1) shpchp 0000:01:00.0: Button pressed on Slot(1-1) shpchp 0000:01:00.0: Card present on Slot(1-1) shpchp 0000:01:00.0: PCI slot #1-1 - powering on due to button press pci 0000:02:01.0: [1b36:0001] type 01 class 0x060400 conventional PCI bridge pci 0000:02:01.0: BAR 0 [mem 0x00000000-0x000000ff 64bit] pci 0000:02:01.0: PCI bridge to [bus 00] pci 0000:02:01.0: bridge window [io 0x0000-0x0fff] pci 0000:02:01.0: bridge window [mem 0x00000000-0x000fffff] pci 0000:02:01.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] pci 0000:02:01.0: No bus number available for hot-added bridge (note: kernel should abort hot-plugging right here) pci 0000:02:01.0: BAR 0 [mem 0xfe600000-0xfe6000ff 64bit]: assigned shpchp 0000:01:00.0: PCI bridge to [bus 02] shpchp 0000:01:00.0: bridge window [io 0xc000-0xcfff] shpchp 0000:01:00.0: bridge window [mem 0xfe600000-0xfe7fffff] shpchp 0000:01:00.0: bridge window [mem 0xfe000000-0xfe1fffff 64bit pref] shpchp 0000:02:01.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 shpchp 0000:02:01.0: enabling device (0000 -> 0002) ACPI: \_SB_.GSIE: Enabled at IRQ 20 BUG: kernel NULL pointer dereference, address: 00000000000000da PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 66 Comm: kworker/1:2 Not tainted 6.9.0-rc1-00001-g2e0239d47d75 #33 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: shpchp-1 shpchp_pushbutton_thread RIP: 0010:shpc_init+0x3fb/0x9d0 [stack dump and register dump cut out] Fix this by aborting the hot-plug if pci_hp_add_bridge() fails. Fixes: 7d01f70ac6f4 ("PCI: shpchp: use generic pci_hp_add_bridge()") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: Yinghai Lu <yinghai(a)kernel.org> Cc: <stable(a)vger.kernel.org> --- v3: revert back to the solution in v1 (calling pci_stop_and_remove_bus_device() and returning negative error code) v2: - add more information to commit description - return 0 instead of -EINVAL drivers/pci/hotplug/shpchp_pci.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/shpchp_pci.c b/drivers/pci/hotplug/shpchp_pci.c index 36db0c3c4ea6..2ac98bdc83d9 100644 --- a/drivers/pci/hotplug/shpchp_pci.c +++ b/drivers/pci/hotplug/shpchp_pci.c @@ -48,8 +48,13 @@ int shpchp_configure_device(struct slot *p_slot) } for_each_pci_bridge(dev, parent) { - if (PCI_SLOT(dev->devfn) == p_slot->device) - pci_hp_add_bridge(dev); + if (PCI_SLOT(dev->devfn) == p_slot->device) { + if (pci_hp_add_bridge(dev)) { + pci_stop_and_remove_bus_device(dev); + ret = -EINVAL; + goto out; + } + } } pci_assign_unassigned_bridge_resources(bridge); -- 2.39.2

11 months, 2 weeks

1
0
0 0

Re: Patch "spi: axi-spi-engine: fix version format string" has been added to the 6.1-stable tree

by David Lechner

On 5/6/24 2:30 PM, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > spi: axi-spi-engine: fix version format string > > to the 6.1-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > spi-axi-spi-engine-fix-version-format-string.patch > and it can be found in the queue-6.1 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > Does not meet the criteria for stable. (only fixes theoretical problem, not actual documented problem)

11 months, 2 weeks

2
2
0 0

Re: Patch "spi: axi-spi-engine: Convert to platform remove callback returning void" has been added to the 6.1-stable tree

by David Lechner

On 5/6/24 2:30 PM, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > spi: axi-spi-engine: Convert to platform remove callback returning void > > to the 6.1-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > spi-axi-spi-engine-convert-to-platform-remove-callba.patch > and it can be found in the queue-6.1 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > Does not meet the criteria for stable.

11 months, 2 weeks

4
7
0 0

[PATCH v2] drm/i915: Fix memory leak by correcting cache object name in error handler

by Jiasheng Jiang

Replace "slab_priorities" with "slab_dependencies" in the error handler to avoid memory leak. Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global") Cc: <stable(a)vger.kernel.org> # v5.2+ Reviewed-by: Nirmoy Das <nirmoy.das(a)intel.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool(a)outlook.com> --- Changelog: v1 -> v2: 1. Alter the subject. --- drivers/gpu/drm/i915/i915_scheduler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c index 762127dd56c5..70a854557e6e 100644 --- a/drivers/gpu/drm/i915/i915_scheduler.c +++ b/drivers/gpu/drm/i915/i915_scheduler.c @@ -506,6 +506,6 @@ int __init i915_scheduler_module_init(void) return 0; err_priorities: - kmem_cache_destroy(slab_priorities); + kmem_cache_destroy(slab_dependencies); return -ENOMEM; } -- 2.25.1

11 months, 2 weeks

1
0
0 0

[PATCH v2] drm/i915: Fix memory leak by correcting cache object name in error handler

by Jiasheng Jiang

Replace "slab_priorities" with "slab_dependencies" in the error handler to avoid memory leak. Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global") Signed-off-by: Jiasheng Jiang <jiashengjiangcool(a)outlook.com> --- Changelog: v1 -> v2: 1. Alter the subject. --- drivers/gpu/drm/i915/i915_scheduler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_scheduler.c b/drivers/gpu/drm/i915/i915_scheduler.c index 762127dd56c5..70a854557e6e 100644 --- a/drivers/gpu/drm/i915/i915_scheduler.c +++ b/drivers/gpu/drm/i915/i915_scheduler.c @@ -506,6 +506,6 @@ int __init i915_scheduler_module_init(void) return 0; err_priorities: - kmem_cache_destroy(slab_priorities); + kmem_cache_destroy(slab_dependencies); return -ENOMEM; } -- 2.25.1

11 months, 2 weeks

2
1
0 0

Old commit back-port

by Alex Elder

This commit landed in Linux v5.16, and should have been back-ported to stable branches: 0ac10b291bee8 arm64: dts: qcom: Fix 'interrupt-map' parent address cells It has three hunks, and the commit can be cherry-picked directly into the 5.15.y and 5.10.y stable branches. The first hunk fixes a problem first introduced in Linux v5.2, so that hunk (only) should be back-ported to v5.4.y. Signed-off-by: Alex Elder <elder(a)linaro.org> Is there anything further I need to do? If you'd prefer I send patches, I can do that also (just ask). Thanks. -Alex Rob's original fix in Linus' tree: 0ac10b291bee8 arm64: dts: qcom: Fix 'interrupt-map' parent address cells This first landed in v5.16. The commit that introduced the problem in the first hunk: b84dfd175c098 arm64: dts: qcom: msm8998: Add PCIe PHY and RC nodes This first landed in v5.2, so back-port to v5.4.y, v5.10.y, v5.15.y. The commit that introduced the problem in the second hunk: 5c538e09cb19b arm64: dts: qcom: sdm845: Add first PCIe controller and PHY This first landed in v5.7, so back-port to v5.10.y, v5.15.y The commit that introduced the problem in the third hunk: 42ad231338c14 arm64: dts: qcom: sdm845: Add second PCIe PHY and controller This first landed in v5.7 also

11 months, 2 weeks

3
2
0 0

FAILED: patch "[PATCH] ASoC: ti: davinci-mcasp: Fix race condition during probe" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x d18ca8635db2f88c17acbdf6412f26d4f6aff414 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024051308-sullen-plug-a6fb@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") 1b4fb70e5b28 ("ASoC: ti: davinci-mcasp: Handle missing required DT properties") 1125d925990b ("ASoC: ti: davinci-mcasp: Simplify the configuration parameter handling") db8793a39b29 ("ASoC: ti: davinci-mcasp: Remove legacy dma_request parsing") 372c4bd11de1 ("ASoC: ti: davinci-mcasp: Use platform_get_irq_byname_optional") 19f6e424d615 ("ASoC: ti: davinci-mcasp: remove always zero of davinci_mcasp_get_dt_params") f4d95de415b2 ("ASoC: ti: davinci-mcasp: remove redundant assignment to variable ret") 764958f2b523 ("ASoC: ti: davinci-mcasp: Support for auxclk-fs-ratio") 540f1ba7b3a5 ("ASoC: ti: davinci-mcasp: Add support for GPIO mode of the pins") 617547175507 ("ASoC: ti: davinci-mcasp: Move context save/restore to runtime_pm callbacks") f2055e145f29 ("ASoC: ti: Merge davinci and omap directories") bc1845498531 ("ASoC: davinci-mcasp: Implement configurable dismod handling") ca3d9433349e ("ASoC: davinci-mcasp: Update PDIR (pin direction) register handling") 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP and Sidetone function split") be51c576e849 ("ASoC: omap-mcbsp: Move out the FIFO check from set_threshold and get_delay") 59d177f65f50 ("ASoC: omap-mcbsp: Simplify the mcbsp_start/_stop function parameters") d63a7625a6df ("ASoC: omap-mcbsp: Clean up the interrupt handlers") c9ece9c29e26 ("ASoC: omap-mcbsp: Skip dma_data.maxburst initialization") dd443a7c0b00 ("ASoC: omap-mcbsp: Clean up dma_data addr initialization code") 2c2596f3ab25 ("ASoC: omap: Remove unused machine driver for AM3517-evm") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d18ca8635db2f88c17acbdf6412f26d4f6aff414 Mon Sep 17 00:00:00 2001 From: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> Date: Wed, 17 Apr 2024 15:41:38 -0300 Subject: [PATCH] ASoC: ti: davinci-mcasp: Fix race condition during probe When using davinci-mcasp as CPU DAI with simple-card, there are some conditions that cause simple-card to finish registering a sound card before davinci-mcasp finishes registering all sound components. This creates a non-working sound card from userspace with no problem indication apart from not being able to play/record audio on a PCM stream. The issue arises during simultaneous probe execution of both drivers. Specifically, the simple-card driver, awaiting a CPU DAI, proceeds as soon as davinci-mcasp registers its DAI. However, this process can lead to the client mutex lock (client_mutex in soc-core.c) being held or davinci-mcasp being preempted before PCM DMA registration on davinci-mcasp finishes. This situation occurs when the probes of both drivers run concurrently. Below is the code path for this condition. To solve the issue, defer davinci-mcasp CPU DAI registration to the last step in the audio part of it. This way, simple-card CPU DAI parsing will be deferred until all audio components are registered. Fail Code Path: simple-card.c: probe starts simple-card.c: simple_dai_link_of: simple_parse_node(..,cpu,..) returns EPROBE_DEFER, no CPU DAI yet davinci-mcasp.c: probe starts davinci-mcasp.c: devm_snd_soc_register_component() register CPU DAI simple-card.c: probes again, finish CPU DAI parsing and call devm_snd_soc_register_card() simple-card.c: finish probe davinci-mcasp.c: *dma_pcm_platform_register() register PCM DMA davinci-mcasp.c: probe finish Cc: stable(a)vger.kernel.org Fixes: 9fbd58cf4ab0 ("ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller") Signed-off-by: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)gmail.com> Reviewed-by: Jai Luthra <j-luthra(a)ti.com> Link: https://lore.kernel.org/r/20240417184138.1104774-1-jpaulo.silvagoncalves@gm… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c index b892d66f7847..1e760c315521 100644 --- a/sound/soc/ti/davinci-mcasp.c +++ b/sound/soc/ti/davinci-mcasp.c @@ -2417,12 +2417,6 @@ static int davinci_mcasp_probe(struct platform_device *pdev) mcasp_reparent_fck(pdev); - ret = devm_snd_soc_register_component(&pdev->dev, &davinci_mcasp_component, - &davinci_mcasp_dai[mcasp->op_mode], 1); - - if (ret != 0) - goto err; - ret = davinci_mcasp_get_dma_type(mcasp); switch (ret) { case PCM_EDMA: @@ -2449,6 +2443,12 @@ static int davinci_mcasp_probe(struct platform_device *pdev) goto err; } + ret = devm_snd_soc_register_component(&pdev->dev, &davinci_mcasp_component, + &davinci_mcasp_dai[mcasp->op_mode], 1); + + if (ret != 0) + goto err; + no_audio: ret = davinci_mcasp_init_gpiochip(mcasp); if (ret) {

11 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] ASoC: ti: davinci-mcasp: Fix race condition during probe" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x d18ca8635db2f88c17acbdf6412f26d4f6aff414 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024051302-deluge-renovate-d904@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") 1b4fb70e5b28 ("ASoC: ti: davinci-mcasp: Handle missing required DT properties") 1125d925990b ("ASoC: ti: davinci-mcasp: Simplify the configuration parameter handling") db8793a39b29 ("ASoC: ti: davinci-mcasp: Remove legacy dma_request parsing") 372c4bd11de1 ("ASoC: ti: davinci-mcasp: Use platform_get_irq_byname_optional") 19f6e424d615 ("ASoC: ti: davinci-mcasp: remove always zero of davinci_mcasp_get_dt_params") f4d95de415b2 ("ASoC: ti: davinci-mcasp: remove redundant assignment to variable ret") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d18ca8635db2f88c17acbdf6412f26d4f6aff414 Mon Sep 17 00:00:00 2001 From: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> Date: Wed, 17 Apr 2024 15:41:38 -0300 Subject: [PATCH] ASoC: ti: davinci-mcasp: Fix race condition during probe When using davinci-mcasp as CPU DAI with simple-card, there are some conditions that cause simple-card to finish registering a sound card before davinci-mcasp finishes registering all sound components. This creates a non-working sound card from userspace with no problem indication apart from not being able to play/record audio on a PCM stream. The issue arises during simultaneous probe execution of both drivers. Specifically, the simple-card driver, awaiting a CPU DAI, proceeds as soon as davinci-mcasp registers its DAI. However, this process can lead to the client mutex lock (client_mutex in soc-core.c) being held or davinci-mcasp being preempted before PCM DMA registration on davinci-mcasp finishes. This situation occurs when the probes of both drivers run concurrently. Below is the code path for this condition. To solve the issue, defer davinci-mcasp CPU DAI registration to the last step in the audio part of it. This way, simple-card CPU DAI parsing will be deferred until all audio components are registered. Fail Code Path: simple-card.c: probe starts simple-card.c: simple_dai_link_of: simple_parse_node(..,cpu,..) returns EPROBE_DEFER, no CPU DAI yet davinci-mcasp.c: probe starts davinci-mcasp.c: devm_snd_soc_register_component() register CPU DAI simple-card.c: probes again, finish CPU DAI parsing and call devm_snd_soc_register_card() simple-card.c: finish probe davinci-mcasp.c: *dma_pcm_platform_register() register PCM DMA davinci-mcasp.c: probe finish Cc: stable(a)vger.kernel.org Fixes: 9fbd58cf4ab0 ("ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller") Signed-off-by: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)gmail.com> Reviewed-by: Jai Luthra <j-luthra(a)ti.com> Link: https://lore.kernel.org/r/20240417184138.1104774-1-jpaulo.silvagoncalves@gm… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c index b892d66f7847..1e760c315521 100644 --- a/sound/soc/ti/davinci-mcasp.c +++ b/sound/soc/ti/davinci-mcasp.c @@ -2417,12 +2417,6 @@ static int davinci_mcasp_probe(struct platform_device *pdev) mcasp_reparent_fck(pdev); - ret = devm_snd_soc_register_component(&pdev->dev, &davinci_mcasp_component, - &davinci_mcasp_dai[mcasp->op_mode], 1); - - if (ret != 0) - goto err; - ret = davinci_mcasp_get_dma_type(mcasp); switch (ret) { case PCM_EDMA: @@ -2449,6 +2443,12 @@ static int davinci_mcasp_probe(struct platform_device *pdev) goto err; } + ret = devm_snd_soc_register_component(&pdev->dev, &davinci_mcasp_component, + &davinci_mcasp_dai[mcasp->op_mode], 1); + + if (ret != 0) + goto err; + no_audio: ret = davinci_mcasp_init_gpiochip(mcasp); if (ret) {

11 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] ASoC: ti: davinci-mcasp: Fix race condition during probe" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x d18ca8635db2f88c17acbdf6412f26d4f6aff414 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024051357-errand-chariot-abc6@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: d18ca8635db2 ("ASoC: ti: davinci-mcasp: Fix race condition during probe") 1b4fb70e5b28 ("ASoC: ti: davinci-mcasp: Handle missing required DT properties") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From d18ca8635db2f88c17acbdf6412f26d4f6aff414 Mon Sep 17 00:00:00 2001 From: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> Date: Wed, 17 Apr 2024 15:41:38 -0300 Subject: [PATCH] ASoC: ti: davinci-mcasp: Fix race condition during probe When using davinci-mcasp as CPU DAI with simple-card, there are some conditions that cause simple-card to finish registering a sound card before davinci-mcasp finishes registering all sound components. This creates a non-working sound card from userspace with no problem indication apart from not being able to play/record audio on a PCM stream. The issue arises during simultaneous probe execution of both drivers. Specifically, the simple-card driver, awaiting a CPU DAI, proceeds as soon as davinci-mcasp registers its DAI. However, this process can lead to the client mutex lock (client_mutex in soc-core.c) being held or davinci-mcasp being preempted before PCM DMA registration on davinci-mcasp finishes. This situation occurs when the probes of both drivers run concurrently. Below is the code path for this condition. To solve the issue, defer davinci-mcasp CPU DAI registration to the last step in the audio part of it. This way, simple-card CPU DAI parsing will be deferred until all audio components are registered. Fail Code Path: simple-card.c: probe starts simple-card.c: simple_dai_link_of: simple_parse_node(..,cpu,..) returns EPROBE_DEFER, no CPU DAI yet davinci-mcasp.c: probe starts davinci-mcasp.c: devm_snd_soc_register_component() register CPU DAI simple-card.c: probes again, finish CPU DAI parsing and call devm_snd_soc_register_card() simple-card.c: finish probe davinci-mcasp.c: *dma_pcm_platform_register() register PCM DMA davinci-mcasp.c: probe finish Cc: stable(a)vger.kernel.org Fixes: 9fbd58cf4ab0 ("ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller") Signed-off-by: Joao Paulo Goncalves <joao.goncalves(a)toradex.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)gmail.com> Reviewed-by: Jai Luthra <j-luthra(a)ti.com> Link: https://lore.kernel.org/r/20240417184138.1104774-1-jpaulo.silvagoncalves@gm… Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c index b892d66f7847..1e760c315521 100644 --- a/sound/soc/ti/davinci-mcasp.c +++ b/sound/soc/ti/davinci-mcasp.c @@ -2417,12 +2417,6 @@ static int davinci_mcasp_probe(struct platform_device *pdev) mcasp_reparent_fck(pdev); - ret = devm_snd_soc_register_component(&pdev->dev, &davinci_mcasp_component, - &davinci_mcasp_dai[mcasp->op_mode], 1); - - if (ret != 0) - goto err; - ret = davinci_mcasp_get_dma_type(mcasp); switch (ret) { case PCM_EDMA: @@ -2449,6 +2443,12 @@ static int davinci_mcasp_probe(struct platform_device *pdev) goto err; } + ret = devm_snd_soc_register_component(&pdev->dev, &davinci_mcasp_component, + &davinci_mcasp_dai[mcasp->op_mode], 1); + + if (ret != 0) + goto err; + no_audio: ret = davinci_mcasp_init_gpiochip(mcasp); if (ret) {

11 months, 2 weeks

1
0
0 0

Excessive memory usage when infiniband config is enabled

by Brian Baboch

Hello, We discovered that the CONFIG_INFINIBAND_IRDMA configuration option in the linux kernel is causing excessive memory usage on idle mode on specific servers like the DELL VEP4600 (https://www.dell.com/en-us/shop/ipovw/virtual-edge-platform-4600. By default we were using Debian's linux-image-6.1.0-13-amd64 which is the stable 6.1.55-1 amd64, we then compiled the kernel again with the same config file from the stable 6.1.55 tag and had the same problem. We were able to resolve the memory problem by removing the `CONFIG_INFINIBAND_IRDMA` option from the kernel config. The tag used to reproduce the problem is v6.1.55. adding the following config `CONFIG_INFINIBAND_IRDMA=m` causes the excessive memory usage to go from 1.4Gb to 7Gb. Here are the 2 config files used and the outputs showing the Memory usage in both cases. Do you have any ideas regarding this bug, we only had this bug on this specific hardware model mentioned above. Debian version of the linux 6.1.55: #uname -a Linux wibox 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux #free -m total used free shared buff/cache available Mem: 15724 6757 8840 3 410 8967 Swap: 0 0 0 Compiled version without INFINIBAND: #uname -a Linux wibox 6.1.55-without-infiniband #75 SMP PREEMPT_DYNAMIC Mon Apr 29 19:06:23 CEST 2024 x86_64 GNU/Linux #free -m total used free shared buff/cache available Mem: 15724 1480 13339 3 1205 14244 Swap: 0 0 0 Thank you,

11 months, 2 weeks

6
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2024