> If I understand this series correctly then this is about a PCI-E card > which has an I2C controller on the card and behind that I2C-controller > there are a couple if I2C muxes + I2C clients. They are not i2c clients in the normal sense. The i2c bus connects to an SFP cage. You can hot plug different sort of network modules into the cage. So for example fibre optic modules or copper modules. The modules have an 'at24' like block of memory, which is a mix of EEPROM and status values. For copper modules, there is an MDIO over I2C protocol which allows access to the Copper Ethernet PHY inside the module. The current device tree binding is that you have a node for the SFP cage, which includes a phandle to the i2c bus, plus a list of GPIOs connected to pins on the SFP cage. The SFP driver will then directly access the memory, maybe instantiate an mdio-over-i2c device if needed, and control the GPIOs. The Ethernet driver then has an OF node with a phandle pointing to the SFP device. The whole design of this is based around the hardware being a collection of standard parts, i2c bus, i2c mux, gpio controller, ethernet controller, each with their own driver as part of a linux subsystem, and then having some glue to put all the parts together. And at the moment, that glue is DT. > Note the above all relies on my interpretation of this patch set, > which may be wrong, since as said the patch-set does seem to be > lacking when it comes to documentation / motivation of the patches. I think some examples from DT will help with this. Andrew
