Message-ID: <20210127075753.GP3565223@nanopsycho.orion>
Date:   Wed, 27 Jan 2021 08:57:53 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Ahern <dsahern@...il.com>, Jakub Kicinski <kuba@...nel.org>,
        netdev@...r.kernel.org, davem@...emloft.net,
        jacob.e.keller@...el.com, roopa@...dia.com, mlxsw@...dia.com,
        vadimp@...dia.com
Subject: Re: [patch net-next RFC 00/10] introduce line card support for
 modular switch

Tue, Jan 26, 2021 at 02:56:08PM CET, andrew@...n.ch wrote:
>On Tue, Jan 26, 2021 at 12:33:26PM +0100, Jiri Pirko wrote:
>> Fri, Jan 22, 2021 at 03:13:12PM CET, andrew@...n.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 <vadimp@...lanox.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 <vadimp@...lanox.com>
>    Reviewed-by: Ido Schimmel <idosch@...lanox.com>
>    Signed-off-by: Jiri Pirko <jiri@...lanox.com>
>    Signed-off-by: David S. Miller <davem@...emloft.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

Powered by blists - more mailing lists