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?