From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Guangshuo Li <lgs201920130244@gmail.com>
Cc: <stable@vger.kernel.org>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
Bard Liao <yung-chuan.liao@linux.intel.com>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
Mark Brown <broonie@kernel.org>,
"Jaroslav Kysela" <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Thorsten Blum <thorsten.blum@linux.dev>,
<linux-sound@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: Intel: SST: fix platform device leak on probe failure
Date: Wed, 23 Sep 2026 10:14:45 +0200 [thread overview]
Message-ID: <af20eb97-2fca-4ab9-9759-90b210b34802@intel.com> (raw)
In-Reply-To: <CANUHTR9F+D1C49MLiiy5z1snyKtbBtdU1cnuhsgr0cysp+yOcQ@mail.gmail.com>
On 9/22/2026 10:17 AM, Guangshuo Li wrote:
> Hi Czarek,
>
> Thanks for the review.
>>> @@ -361,15 +362,21 @@ static int sst_acpi_probe(struct platform_device *pdev)
>>>
>>> ret = sst_platform_get_resources(ctx);
>>> if (ret)
>>> - return ret;
>>> + goto err_unregister_mdev;
>>>
>>> ret = sst_context_init(ctx);
>>> if (ret < 0)
>>> - return ret;
>>> + goto err_unregister_mdev;
>>>
>>> sst_configure_runtime_pm(ctx);
>>> platform_set_drvdata(pdev, ctx);
>>> return ret;
>>> +
>>> +err_unregister_mdev:
>>> + platform_device_unregister(mdev);
>>> +err_unregister_plat_dev:
>>> + platform_device_unregister(plat_dev);
>>> + return ret;
>>> }
>>
>> Looks like sst_acpi_remove() does not unregister the devices either.
>> That could be fixed by enlisting devm_add_action_or_reset() in
>> sst_acpi_probe() without altering sst_acpi_remove() at all.
>>
>> Would you mind sending a separate patch updating the function so both
>> the error path and the driver-unload clean up the device objects?
>>
>>
>> Kind regards,
>> Czarek
>
> I'll update the title to:
>
> ASoC: Intel: atom: Fix platform device leak on probe failure
>
> and trim the commit message as suggested, including the
> s/machine drivers/machine board/ change. I'll also add your Reviewed-by.
>
> For the separate cleanup patch, do you mean something like this?
>
> +static void sst_unregister_platform_device(void *data)
> +{
> + platform_device_unregister(data);
> +}
> +
> plat_dev = platform_device_register_data(...);
> if (IS_ERR(plat_dev))
> return PTR_ERR(plat_dev);
> +
> + ret = devm_add_action_or_reset(dev, sst_unregister_platform_device,
> + plat_dev);
> + if (ret)
> + return ret;
>
> ...
>
> mdev = platform_device_register_data(...);
> if (IS_ERR(mdev))
> return PTR_ERR(mdev);
> +
> + ret = devm_add_action_or_reset(dev, sst_unregister_platform_device,
> + mdev);
> + if (ret)
> + return ret;
>
> This would let devres clean up both devices on later probe failure and on
> driver unload, so the explicit unregister error paths from the first patch
> would no longer be needed after this patch.
>
> Would this be what you had in mind? If so, I'll follow Krzysztof's
> suggestion, organize the related changes into a proper patch series,
> and send a two-patch v2.
I do not mind either approach. There are two problems here:
1) leak on probe() failure
2) leak on driver remove()
So, two patches-approach IMHO is perfectly fine. And yes, enlisting
devm_add_action_or_reset() closes both 1) and 2) in one go.
Kind regards,
Czarek
next prev parent reply other threads:[~2026-09-23 8:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:38 Guangshuo Li
2026-09-21 9:31 ` Cezary Rojewski
2026-09-22 8:17 ` Guangshuo Li
2026-09-23 8:14 ` Cezary Rojewski [this message]
2026-09-21 15:06 ` krzk
2026-09-22 2:47 ` Guangshuo Li
2026-09-21 15:09 ` krzk
2026-09-21 15:12 ` krzk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af20eb97-2fca-4ab9-9759-90b210b34802@intel.com \
--to=cezary.rojewski@intel.com \
--cc=broonie@kernel.org \
--cc=kai.vehmanen@linux.intel.com \
--cc=lgs201920130244@gmail.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=stable@vger.kernel.org \
--cc=thorsten.blum@linux.dev \
--cc=tiwai@suse.com \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®