[PATCH v5 1/2] ASoC: cs35l41: CS35L41 Boosted Smart Amplifier

[Richard Fitzgerald]

On 03/09/2021 14:58, Pierre-Louis Bossart wrote:
> 
> 
>>> Is the ACPI probe smart enough to deal with two different drivers
>>> registering for the *same* HID?
>>>
>>> I haven't seen any precedent, e.g. the RT6777 uses a different ACPI HID
>>> for its I2C and SPI modes.
>>>
>>>
>>
>> I2C and SPI buses, when they are looking for a driver with an ID that
>> matches a device declared in ACPI, will iterate over drivers that belong
>> to the bus only (bus_for_each_drv()). It is not possible for an I2C
>> driver to be matched during SPI device enumeration or vice versa.
> 
> That's good but that use of the same HID for two different solutions is
> still be problematic. On ACPI solutions, we use the HID as a key to
> identify what machine driver to load, see e.g. snd_soc_acpi_find_machine().

We know that HIDs are required to setup machine-specific stuff, but that
doesn't prevent having a generic ID string. We still allocate a generic
ACPI ID for the part. As machine-specific HIDs are likely, there's no
strong reason to allocate two generic IDs for the same part.

Unfortunately we don't have a crystal ball to be able to include now all
the machine-unique HIDs that will be allocated in the future, so they
will have to be added when they exist.

> By using the *same* HID, you will prevent that machine detection from
> uniquely identifying what mode is used, and force the machine detection
> to be expanded with e.g. DMI-based quirks. It's really far from ideal
> for integrators. The only case where this would work with impacts on the
> machine selection would be if the choice of the SPI and I2C modes had no
> impact on the functionality of the device, but is this really the case?
> 

I can't think what you'd need to setup differently in a machine driver
for I2C versus SPI control. Do you have the bus ID hardcoded into your
machine drivers for some reason?