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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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/cht_bsw_rt5645.c#L480
http://elixir.free-electrons.com/linux/latest/source/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c#L37
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
