On Fri, Sep 03, 2021 at 08:58:17AM -0500, Pierre-Louis Bossart wrote: > > 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 You can always add the bus type as a key if you really need to? > 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? Usually that's the case for CODECs, it's just going to be a question of how fast the I/O is, physical design considerations and what interfaces you have available. It'll be limiting for some applications of course (slow firmware downloads for example) but given the way these things are built I'd be fairly surprised to see something actively gated off. If you look at the I2C and SPI bus handling for individual CODECs they're usually extremely thin wrapper that just pass a regmap into common code with nothing else done conditionally.
Attachment:
signature.asc
Description: PGP signature
