Re: [PATCH v2 1/3] ACPI / utils: Introduce acpi_dev_get_dev_name()

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

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/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.
> 
>