mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®