Tue, Jan 26, 2021 at 02:56:08PM CET, and...@lunn.ch wrote: >On Tue, Jan 26, 2021 at 12:33:26PM +0100, Jiri Pirko wrote: >> Fri, Jan 22, 2021 at 03:13:12PM CET, and...@lunn.ch wrote: >> >> I don't see any way. The userspace is the one who can get the info, from >> >> the i2c driver. The mlxsw driver has no means to get that info itself. >> > >> >Hi Jiri >> > >> >Please can you tell us more about this i2c driver. Do you have any >> >architecture pictures? >> >> Quoting Vadim Pasternak: >> " >> Not upstreamed yet. >> It will be mlxreg-lc driver for line card in drivers/platfrom/mellanox and >> additional mlxreg-pm for line card powering on/off, setting enable/disable >> and handling power off upon thermal shutdown event. >> " >> >> >> > >> >It is not unknown for one driver to embed another driver inside it. So >> >the i2c driver could be inside the mlxsw. It is also possible to link >> >drivers together, the mlxsw could go find the i2c driver and make use >> >of its services. >> >> Okay. Do you have examples? How could the kernel figure out the relation >> of the instances? > >Hi Jiri > >One driver, embedded into another? You actually submitted an example: > >commit 6882b0aee180f2797b8803bdf699aa45c2e5f2d6 >Author: Vadim Pasternak <vad...@mellanox.com> >Date: Wed Nov 16 15:20:44 2016 +0100 > > mlxsw: Introduce support for I2C bus > > Add I2C bus implementation for Mellanox Technologies Switch ASICs. > This includes command interface implementation using input / out mailboxes, > whose location is retrieved from the firmware during probe time. > > Signed-off-by: Vadim Pasternak <vad...@mellanox.com> > Reviewed-by: Ido Schimmel <ido...@mellanox.com> > Signed-off-by: Jiri Pirko <j...@mellanox.com> > Signed-off-by: David S. Miller <da...@davemloft.net> > >There are Linux standard APIs for controlling the power to devices, >the regulator API. So i assume mlxreg-pm will make use of that. There >are also standard APIs for thermal management, which again, mlxreg-pm >should be using. The regulator API allows you to find regulators by >name. So just define a sensible naming convention, and the switch >driver can lookup the regulator, and turn it on/off as needed.
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? 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'm guessing there are no standard Linux API which mlxreg-lc fits. I'm >also not sure it offers anything useful standalone. So i would >actually embed it inside the switchdev driver, and have internal APIs >to get information about the line card. > >But i'm missing big picture architecture knowledge here, there could >be reasons why these suggestions don't work. > > Andrew
