* RE: [PATCH 1/2] ALSA: hda: cs35l56: Put ACPI device after setting companion
[not found] ` <20260428104044.GA1898666@chcpu16>
@ 2026-05-06 14:37 ` Simon Trimmer
0 siblings, 0 replies; 2+ messages in thread
From: Simon Trimmer @ 2026-05-06 14:37 UTC (permalink / raw)
To: 'Shuhao Fu', 'David Rhodes',
'Richard Fitzgerald'
Cc: 'Jaroslav Kysela', 'Takashi Iwai', linux-sound,
patches, linux-kernel
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>
^ permalink raw reply [flat|nested] 2+ messages in thread