Hi Geert,

finally going back to this topic.

> I'm mostly approaching this from the DT point of view, as DT describes the
> hardware, so the description should reflect the actual hardware topology as
> closely as possible.
> 
> Currently DT describes (let's keep using i2c as an example):
>   - one ore more i2c masters (in .dtsi),
>   - an i2c bus (in .dts), which is a child of one particular i2c master node,
>   - pinctrl (in .dts) to link the i2c bus to one particular i2c master.
> 
> Obviously this does not match the hardware, as
>   (1) pinctrl is dynamic, and
>   (2) the i2c bus is not hard-tied to that specific i2c master instance.
> 
> What does describe the hardware is:
>   - one or more i2c masters (in .dtsi),
>   - pinctrl for the i2c masters (tables/code under drivers/pinctrl/),
>   - an i2c bus (in .dts), defined by actual pin connections,
>   - pinctrl (in .dts) to link the pin connections used by the i2c bus to one
>     default i2c master (is this needed?).
> With the above description, switching can be controlled from pinctrl,
> triggered by the user or by availability of drivers and/or QoS.

If I understood correctly, we currently can't describe this in DT this
way. If we wanted to connect a bus to pins, we need to tie it to the pin
names like "GP5_5" for SCL and "GP5_6" to SDA. We don't have those, we
only have the function groups like "iic2" or "i2c2". And even if we had
those, we would need a reverse mapping to check if "GP5_5" can be
configured to this or that I2C core. Or?

> Your "i2c-demux" in DT is actually a description of an i2c bus.
> But instead of linking it to pins, it contains a list of all i2c masters.

Yes, one layer of indirection. The list is (currently) only used to get
the desired pin mapping.

> If I want to add an i2c-gpio master, I'll have to add it to DT. That sounds
> insignificant, but (in theory) all I/O masters could be implemented using GPIO.
> So one day someone may implement an xxx-gpio driver for whatever bus,
> and I think it should be supported out-of-the-box. When using pins, and thus
> describing the i2c bus in a pin-centric way, that will just work.

If my assumption about the reverse mapping above holds true, I don't
think this is worth the hazzle?

Thanks for your feedback!

   Wolfram