OTOH, if that is true, we shouldn't select SOFTWARE_I2C from a driver
because it disables platform_i2c_tansfer() and who knows when it is
needed?

CONFIG(SOFTWARE_I2C) only says that the software I2C code is compiled in, it doesn't mean you can't still use hardware I2C controllers. The way it's designed right now it will still always use hardware by default unless you explicitly enable software I2C (by setting the software_i2c[bus] pointer to something non-NULL).

I see, now. Missed that a software I2C bus must be registered to override
a hardware one. It's just the way it's used here that confuses me too much.

> > My current hunch would be to redesign software i2c so one can use it
> > to implement i2c_bus. And deprecate i2c_simple anyway for everything
> > that might remotely have a second controller chip on board.
>
> I'll have a look at this next year.

i2c_simple is still used for all non-x86 devices, and we'll probably want to keep it that way since i2c_bus is specific to devicetree, which is only used on x86. Making software I2C a possible backend for i2c_bus sounds reasonable, but please don't kill i2c_simple.

Yeah, that's why I wrote "for everything that might remotely have a second
controller chip on board". I know there are some simple SoC based boards that
don't need the devicetree complexity. But for all cases where you want to
support multiple chips with one interface, dt is just the way to go, imo.

View Change

To view, visit change 35726. To unsubscribe, or for help writing mail filters, visit settings.