[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YBAfeESYudCENZ2e@lunn.ch>
Date: Tue, 26 Jan 2021 14:56:08 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jiri Pirko <jiri@...nulli.us>
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
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'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