RE: [PATCH 1/2] ALSA: hda: cs35l56: Put ACPI device after setting companion

RE: [PATCH 1/2] ALSA: hda: cs35l56: Put ACPI device after setting companion

[Simon Trimmer]

On 28/04/2026 11:41 am, Shuhao Fu wrote:
> Hi Richard,
> 
> > Are you sure about this?
> > I remember when I wrote this code I checked the driver core and saw that
> > if there is a companion it puts it when the driver is removed.
> > That is why I didn't put the reference here, it would have caused a
> > double put.
> 
> I may well be missing something here. But from my reading of the current
> code, it does not seem to cause a double put.
> 
> The place where I do seem to find ACPI companion cleanup is when the
> device
> object itself is deleted/unregistered:
> 
>   `device_del()`
>     -> `device_platform_notify_remove()`
>     -> `acpi_device_notify_remove()`
>     -> `acpi_unbind_one()`
> 
> What makes me think this is not the matching put for
> `acpi_dev_get_first_match_dev()` is that `acpi_unbind_one()` only calls
> `acpi_dev_put()` after it finds a matching entry for the device in
> `acpi_dev->physical_node_list`.
> 
> As far as I can tell, that list entry is created by `acpi_bind_one()`,
which
> also takes its own extra reference with `acpi_dev_get(acpi_dev)`. So the
put
> in `acpi_unbind_one()` looks to me like it is paired with that
> `acpi_bind_one()` reference, rather than with the earlier
> `acpi_dev_get_first_match_dev()` lookup.
> 
> If that reading is right, then I think the ownership looks like this:
> 
> - `ACPI_COMPANION_SET()` only attaches the companion pointer/fwnode
> - the lookup reference from `acpi_dev_get_first_match_dev()` is still with
>   the caller
> - `acpi_dev_put(adev)` after `ACPI_COMPANION_SET()` balances only that
>   lookup reference
> - the later `acpi_unbind_one()` path would not be putting the same
>   reference again, because that put is for the separate ref taken by
>   `acpi_bind_one()`
> 
> Part of why I leaned that way is that I found a couple of in-tree examples
> that seem to follow the same pattern:
> 
> - `drivers/platform/x86/x86-android-tablets/core.c`
>   does `acpi_dev_get_first_match_dev()`, `ACPI_COMPANION_SET()`, then
>   `acpi_dev_put()`
> 
> - `drivers/acpi/arm64/mpam.c`
>   does `acpi_dev_get_first_match_dev()`, `ACPI_COMPANION_SET()`, then
>   `acpi_dev_put()`
> 
> So from my own understanding, those examples also seem to treat
> `ACPI_COMPANION_SET()` as not consuming the reference returned by
> `acpi_dev_get_first_match_dev()`.
> 
> But this is only my reading of the current ownership flow, so if I am
> overlooking some rule around manually assigned companions I am happy to
> re-check.
> 
> Best regards,
> Shuhao

Tested-by: Simon Trimmer <simont@opensource.cirrus.com>

Re: [PATCH 0/2] ALSA: hda: Fix Cirrus ACPI device reference leaks

[Takashi Iwai]

On Tue, 28 Apr 2026 09:44:15 +0200,
Shuhao Fu wrote:
> 
> This series fixes two missing acpi_dev_put() cases in Cirrus HDA side-codec
> ACPI lookup paths.
> 
> Patch 1 drops the lookup reference after synthesizing the companion in
> cs35l56_hda_read_acpi().
> 
> Patch 2 drops the lookup reference on the early !physdev error path in
> cs35l41_hda_read_acpi().
> 
> Shuhao Fu (2):
>   ALSA: hda: cs35l56: Put ACPI device after setting companion
>   ALSA: hda: cs35l41: Fix ACPI device leak on missing physical node

Assuming that the logic is correct, I applied both now.


thanks,

Takashi