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?
