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

 sound/hda/codecs/side-codecs/cs35l41_hda.c | 4 +++-
 sound/hda/codecs/side-codecs/cs35l56_hda.c | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

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

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

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>