On 1/27/21 7:14 AM, Andrew Lunn wrote: >> I don't think it would apply. The thing is, i2c driver has a channel to >> the linecard eeprom, from where it can read info about the linecard. The >> i2c driver also knows when the linecard is plugged in, unlike mlxsw. >> It acts as a standalone driver. Mlxsw has no way to directly find if the >> card was plugged in (unpowered) and which type it is. >> >> Not sure how to "embed" it. I don't think any existing API could help. >> Basicall mlxsw would have to register a callback to the i2c driver >> called every time card is inserted to do auto-provision. >> Now consider a case when there are multiple instances of the ASIC on the >> system. How to assemble a relationship between mlxsw instance and i2c >> driver instance? > > You have that knowledge already, otherwise you cannot solve this > problem at all. The switch is an PCIe device right? So when the bus is > enumerated, the driver loads. How do you bind the i2c driver to the > i2c bus? You cannot enumerate i2c, so you must have some hard coded > knowledge somewhere? You just need to get that knowledge into the > mlxsw driver so it can bind its internal i2c client driver to the i2c > bus. That way you avoid user space, i guess maybe udev rules, or some > daemon monitoring propriety /sys files? > >> But again, auto-provision is only one usecase. Manual provisioning is >> needed anyway. And that is exactly what my patchset is aiming to >> introduce. Auto-provision can be added when/if needed later on. > > I still don't actually get this use case. Why would i want to manually > provision? >
+1.
