[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YBdc3c26Af6chAZM@lunn.ch>
Date: Mon, 1 Feb 2021 02:43:57 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vadim Pasternak <vadimp@...dia.com>
Cc: Jiri Pirko <jiri@...nulli.us>, David Ahern <dsahern@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"jacob.e.keller@...el.com" <jacob.e.keller@...el.com>,
Roopa Prabhu <roopa@...dia.com>, mlxsw <mlxsw@...dia.com>
Subject: Re: [patch net-next RFC 00/10] introduce line card support for
modular switch
> Platform line card driver is aware of line card I2C topology, its
> responsibility is to detect line card basic hardware type, create I2C
> topology (mux), connect all the necessary I2C devices, like hotswap
> devices, voltage and power regulators devices, iio/a2d devices and line
> card EEPROMs, creates LED instances for LED located on a line card, exposes
> line card related attributes, like CPLD and FPGA versions, reset causes,
> required powered through line card hwmon interface.
Jiri says the hardware is often connected to the BMC. But you do
expose much of this to the host as well? You want devlink dev info to
show the version information. Use devlink dev flash to upgrade the
bitfile in the CPD and FPGA. The hwmon instances are pretty pointless
on the BMC where nobody can see them. Are there temperature sensors
involved? The host is where the thermal policy is running, deciding
what to throttle, or shut down when it gets too hot. LEDs can be
controlled via /sys/class/led as expected?
So exporting what the line card actually is to the host is not really
a problem, it is just one more bit of information amongst everything
else already exposed to it.
Andrew
Powered by blists - more mailing lists