On 1/5/18 6:39 AM, Andy Shevchenko wrote:
On Fri, 2018-01-05 at 13:34 +0100, Rafael J. Wysocki wrote:
On Fri, Jan 5, 2018 at 1:22 PM, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, 2018-01-05 at 13:06 +0100, Rafael J. Wysocki wrote:
On Thu, Jan 4, 2018 at 5:47 PM, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
"Subset of Intel ASoC drivers is an existing user of this API when they need to find an actual instance of the codec device based on its ACPI HID."
And why do they need the name (and not something else)?
I don't know the guts of Intel ASoC implementation, so, can't answer this without investigation.
Pierre, can you elaborate this piece?
Because the ASoC DAI structures use strings to represent the codec name. See e.g.
http://elixir.free-electrons.com/linux/latest/source/sound/soc/intel/boards/... http://elixir.free-electrons.com/linux/latest/source/sound/soc/intel/boards/...
In most cases a hard-coded name is fine, except when the BIOS uses a different HID or the ACPI subsystem changes the :00 ending to :01
So what the code does is that you look for a set of known HIDs, create the machine driver and pass the HID as pdata, then in the machine driver once you query the string that lets ASoC do the rest of the card creation.
You can argue that ASoC should not use strings, but that's not really a debate at this point: all I am trying to do is to make devices work when their BIOS is slightly different from the norm.
So, acpi_dev_get_name() then?
It would be somewhat clearer to call it acpi_dev_get_first_match_name() IMO.
Otherwise it may not be clear what name this is going to return.
Works for me.