> > The second way is to have a number of #ifdef and complex > > Kconfig dependencies for the driver to only register the > > device_driver objects for the buses that are enabled. This > > is also doable, but everyone gets the logic wrong the first time. > > Hm, I understand now why you'd prefer to have a single bus. Can't we > solve this problem with a module_i3c_i2c_driver() macro that would hide > all this complexity from I2C/I3C drivers? Do you know of devices speaking both i3c and i2c as of today? I think I3C/I2C is a bit different than I2C/SPI. For the latter, it might happen that you have only this or that bus on the board, so it makes sense to support both. But if you have I3C, you can simply attach the I2C device onto it. I guess you would only implement I3C in the device if you explicitly need its feature set. And then, a I2C fallback doesn't make much sense? Or am I missing something? OK, now I know that those I3C+I2C devices will exist, even if only for Murphy's law. However, my assumptions would be that those devices are not common and so we could live with the core plus bus_drivers seperation we have for SPI/I2C already (although I would love a common regmap-based I2C/SPI abstraction).
Attachment:
signature.asc
Description: PGP signature
