>> 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(). 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?