From: Shuhao Fu <sfual@cse.ust.hk>
To: David Rhodes <david.rhodes@cirrus.com>,
Richard Fitzgerald <rf@opensource.cirrus.com>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
linux-sound@vger.kernel.org, patches@opensource.cirrus.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ALSA: hda: cs35l56: Put ACPI device after setting companion
Date: Tue, 28 Apr 2026 18:40:44 +0800 [thread overview]
Message-ID: <20260428104044.GA1898666@chcpu16> (raw)
In-Reply-To: <20260428074415.GA1632446@chcpu16>
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
prev parent reply other threads:[~2026-04-28 10:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 7:44 [PATCH 0/2] ALSA: hda: Fix Cirrus ACPI device reference leaks Shuhao Fu
2026-04-28 8:01 ` [PATCH 1/2] ALSA: hda: cs35l56: Put ACPI device after setting companion Shuhao Fu
2026-04-28 9:05 ` Richard Fitzgerald
2026-04-28 8:12 ` [PATCH 2/2] ALSA: hda: cs35l41: Put ACPI device on missing physical node Shuhao Fu
2026-04-28 10:40 ` Shuhao Fu [this message]
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=20260428104044.GA1898666@chcpu16 \
--to=sfual@cse.ust.hk \
--cc=david.rhodes@cirrus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=perex@perex.cz \
--cc=rf@opensource.cirrus.com \
--cc=tiwai@suse.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