[PATCH 1/3] ASoC: amd: acp: Fix NULL pointer deref on acp resume path
update chip data using dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev).
BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: <TASK> ? __pfx_platform_pm_resume+0x10/0x10 platform_pm_resume+0x28/0x60 dpm_run_callback+0x51/0x1a0 device_resume+0x1a6/0x2b0 dpm_resume+0x168/0x230
Fixes: e3933683b25e ("ASoC: amd: acp: Remove redundant acp_dev_data structure")
Signed-off-by: Venkata Prasad Potturu venkataprasad.potturu@amd.com --- sound/soc/amd/acp/acp-rembrandt.c | 2 +- sound/soc/amd/acp/acp-renoir.c | 2 +- sound/soc/amd/acp/acp63.c | 2 +- sound/soc/amd/acp/acp70.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/amd/acp/acp-rembrandt.c b/sound/soc/amd/acp/acp-rembrandt.c index 746b6ed72029..cccdd10c345e 100644 --- a/sound/soc/amd/acp/acp-rembrandt.c +++ b/sound/soc/amd/acp/acp-rembrandt.c @@ -199,7 +199,7 @@ static void rembrandt_audio_remove(struct platform_device *pdev)
static int rmb_pcm_resume(struct device *dev) { - struct acp_chip_info *chip = dev_get_platdata(dev); + struct acp_chip_info *chip = dev_get_drvdata(dev->parent); struct acp_stream *stream; struct snd_pcm_substream *substream; snd_pcm_uframes_t buf_in_frames; diff --git a/sound/soc/amd/acp/acp-renoir.c b/sound/soc/amd/acp/acp-renoir.c index ebf0106fc737..04f6d70b6a92 100644 --- a/sound/soc/amd/acp/acp-renoir.c +++ b/sound/soc/amd/acp/acp-renoir.c @@ -146,7 +146,7 @@ static void renoir_audio_remove(struct platform_device *pdev)
static int rn_pcm_resume(struct device *dev) { - struct acp_chip_info *chip = dev_get_platdata(dev); + struct acp_chip_info *chip = dev_get_drvdata(dev->parent); struct acp_stream *stream; struct snd_pcm_substream *substream; snd_pcm_uframes_t buf_in_frames; diff --git a/sound/soc/amd/acp/acp63.c b/sound/soc/amd/acp/acp63.c index 52d895e624c7..1f15c96a9b94 100644 --- a/sound/soc/amd/acp/acp63.c +++ b/sound/soc/amd/acp/acp63.c @@ -250,7 +250,7 @@ static void acp63_audio_remove(struct platform_device *pdev)
static int acp63_pcm_resume(struct device *dev) { - struct acp_chip_info *chip = dev_get_platdata(dev); + struct acp_chip_info *chip = dev_get_drvdata(dev->parent); struct acp_stream *stream; struct snd_pcm_substream *substream; snd_pcm_uframes_t buf_in_frames; diff --git a/sound/soc/amd/acp/acp70.c b/sound/soc/amd/acp/acp70.c index 6d5f5ade075c..217b717e9beb 100644 --- a/sound/soc/amd/acp/acp70.c +++ b/sound/soc/amd/acp/acp70.c @@ -182,7 +182,7 @@ static void acp_acp70_audio_remove(struct platform_device *pdev)
static int acp70_pcm_resume(struct device *dev) { - struct acp_chip_info *chip = dev_get_platdata(dev); + struct acp_chip_info *chip = dev_get_drvdata(dev->parent); struct acp_stream *stream; struct snd_pcm_substream *substream; snd_pcm_uframes_t buf_in_frames;
Update chip data using dev_get_drvdata(dev->parent) to fix NULL pointer deref in acp_i2s_set_tdm_slot.
Fixes: cd60dec8994c ("ASoC: amd: acp: Refactor TDM slots selction based on acp revision id")
Signed-off-by: Venkata Prasad Potturu venkataprasad.potturu@amd.com --- sound/soc/amd/acp/acp-i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/amd/acp/acp-i2s.c b/sound/soc/amd/acp/acp-i2s.c index a38409dd1d34..70fa54d568ef 100644 --- a/sound/soc/amd/acp/acp-i2s.c +++ b/sound/soc/amd/acp/acp-i2s.c @@ -97,7 +97,7 @@ static int acp_i2s_set_tdm_slot(struct snd_soc_dai *dai, u32 tx_mask, u32 rx_mas struct acp_stream *stream; int slot_len, no_of_slots;
- chip = dev_get_platdata(dev); + chip = dev_get_drvdata(dev->parent); switch (slot_width) { case SLOT_WIDTH_8: slot_len = 8;
Add condition check to fix devm_snd_soc_register_card(acp-pdm-mach) deferred probe failure, when pdm DSD entry is not available.
[15.910456] acp_mach acp-pdm-mach: devm_snd_soc_register_card(acp-pdm-mach) failed: -517 [15.910536] platform acp-pdm-mach: deferred probe pending: (reason unknown)
Fixes: 6e60db74b69c2 ("ASoC: amd: acp: Refactor acp machine select")
Signed-off-by: Venkata Prasad Potturu venkataprasad.potturu@amd.com --- sound/soc/amd/acp/acp-legacy-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/amd/acp/acp-legacy-common.c b/sound/soc/amd/acp/acp-legacy-common.c index b4d68484e06d..ba8db0851daa 100644 --- a/sound/soc/amd/acp/acp-legacy-common.c +++ b/sound/soc/amd/acp/acp-legacy-common.c @@ -450,7 +450,7 @@ int acp_machine_select(struct acp_chip_info *chip) struct snd_soc_acpi_mach *mach; int size, platform;
- if (chip->flag == FLAG_AMD_LEGACY_ONLY_DMIC) { + if (chip->flag == FLAG_AMD_LEGACY_ONLY_DMIC && chip->is_pdm_dev) { platform = chip->acp_rev; chip->mach_dev = platform_device_register_data(chip->dev, "acp-pdm-mach", PLATFORM_DEVID_NONE, &platform,
On Fri, Apr 25, 2025 at 10:55:16AM +0200, Markus Elfring wrote:
update chip data using dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev).
…
Would you get into the mood to replace the text “deref” in the summary phrase?
Can a cover letter usually be helpful for such a patch series?
Regards, Markus
Hi,
This is the semi-friendly patch-bot of Greg Kroah-Hartman.
Markus, you seem to have sent a nonsensical or otherwise pointless review comment to a patch submission on a Linux kernel developer mailing list. I strongly suggest that you not do this anymore. Please do not bother developers who are actively working to produce patches and features with comments that, in the end, are a waste of time.
Patch submitter, please ignore Markus's suggestion; you do not need to follow it at all. The person/bot/AI that sent it is being ignored by almost all Linux kernel maintainers for having a persistent pattern of behavior of producing distracting and pointless commentary, and inability to adapt to feedback. Please feel free to also ignore emails from them.
thanks,
greg k-h's patch email bot
On Fri, Apr 25, 2025 at 10:55:16AM +0200, Markus Elfring wrote:
update chip data using dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev).
Would you get into the mood to replace the text “deref” in the summary phrase?
Can a cover letter usually be helpful for such a patch series?
Feel free to ignore Markus, he has a long history of sending unhelpful review comments and continues to ignore repeated requests to stop.
On Fri, 25 Apr 2025 11:31:39 +0530, Venkata Prasad Potturu wrote:
update chip data using dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev).
BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace:
<TASK> ? __pfx_platform_pm_resume+0x10/0x10 platform_pm_resume+0x28/0x60 dpm_run_callback+0x51/0x1a0 device_resume+0x1a6/0x2b0 dpm_resume+0x168/0x230
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/3] ASoC: amd: acp: Fix NULL pointer deref on acp resume path commit: ba85883d160515129b58873f74376a89faf21c7c [2/3] ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot commit: 6d9b64156d849e358cb49b6b899fb0b7d262bda8 [3/3] ASoC: amd: acp: Fix devm_snd_soc_register_card(acp-pdm-mach) failure commit: 138e6da0392ed067d0db7b5b5b4582c3668cfcf9
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
On Fri, 2025-04-25 at 11:31 +0530, Venkata Prasad Potturu wrote:
update chip data using dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev).
BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace:
<TASK> ? __pfx_platform_pm_resume+0x10/0x10 platform_pm_resume+0x28/0x60 dpm_run_callback+0x51/0x1a0 device_resume+0x1a6/0x2b0 dpm_resume+0x168/0x230
Fixes: e3933683b25e ("ASoC: amd: acp: Remove redundant acp_dev_data structure")
Signed-off-by: Venkata Prasad Potturu venkataprasad.potturu@amd.com
This is the first time I see an empty line between the Fixes and the Signed-off-by tags. I checked checkpatch.pl --strict and that doesn't complain, but I'm curious now, is that a subsystem thing since you have it in all 3 patches?
sound/soc/amd/acp/acp-rembrandt.c | 2 +- sound/soc/amd/acp/acp-renoir.c | 2 +- sound/soc/amd/acp/acp63.c | 2 +- sound/soc/amd/acp/acp70.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
--- snip ---
index 6d5f5ade075c..217b717e9beb 100644 --- a/sound/soc/amd/acp/acp70.c +++ b/sound/soc/amd/acp/acp70.c @@ -182,7 +182,7 @@ static void acp_acp70_audio_remove(struct platform_device *pdev)
static int acp70_pcm_resume(struct device *dev) {
- struct acp_chip_info *chip = dev_get_platdata(dev);
- struct acp_chip_info *chip = dev_get_drvdata(dev->parent); struct acp_stream *stream; struct snd_pcm_substream *substream; snd_pcm_uframes_t buf_in_frames;
Hi Venkata,
Yesterday I ran into what I believe is the issue fixed by this patch on my very recently acquired Framework 13 with a Ryzen AI 340. While I was still bisecting this I found a thread[0] of Jacek Luczak having bisected this and the revert at least solved the suspend issue for me too, though I was still getting a sound subsystem related crash[2] that looked related so was waiting for a proper fix. As a side note you might want to consider adding a Reported-by tag from Jacek.
I had mentioned this on the Framework forums[1] where Mario Limonciello helpfully pointed me at this series. I just tried your series on top of v6.15-rc4 and suspend now works. I also haven't seen the other crash I was still getting with just the revert from the previous thread. And sound still works too. So feel free to add, or ignore, my:
Tested-by: Niklas Schnelle niks@kernel.org
Thanks, Niklas
[0] https://lore.kernel.org/lkml/CADDYkjR0JG_JTQeQMAvUJvtb9RxFH6_LzV2Fr_1cnqPTgV... [1] https://community.frame.work/t/regression-framework-13-ryzen-340-doesnt-wake... [2] https://pastebin.com/pR54sve3
participants (5)
-
Greg Kroah-Hartman -
Mark Brown -
Markus Elfring -
Niklas Schnelle -
Venkata Prasad Potturu