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

[Shuhao Fu]

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