Re: [PATCH RFC] net: sfp: support assigning status LEDs to SFP connectors

[Andrew Lunn <andrew@lunn.ch>]

On Mon, May 09, 2022 at 03:29:38PM +0300, Josua Mayer wrote:
> Dear Maintainers,
> 
> I am working on a new device based on the LX2160A platform, that exposes
> 16 sfp connectors, each with its own led controlled by gpios intended
> to show link status.

Can you define link status? It is a messy concept with SFPs. Is it
!LOS? I guess not, because you would not of used a GPIO, just hard
wired it. Does it mean the SERDES has sync? Does it reflect the netdev
carrier status?

> We have found that there is a way in sysfs to echo the name of the network
> device to the api of the led driver, and it will start showing link status.
> However this has to be done at runtime by the user.

Please take a look at the patches Ansuel Smith submitted last week,
maybe the week before last.

> On the Layerscape platform in particular these devices are created dynamically
> by the networkign coprocessor, which supports complex functions such as
> creating one network interface that spans multiple ports.

The linux model is that each MAC has a netdev, hence a name. If you
need to span multiple ports, you then add a bridge and add the MACs to
the bridge. So there should not be an issue here.

> It seems to me that the netdev trigger therefore can not properly reflect
> the relation between an LED (which is hard-wired to an sfp cage), and the
> link state reported by e.g. a phy inside an sfp module.

The netdev carrier will correctly reflect this.

> You may notice that again leds are tied to existence of a particular logical
> network interface, which may or may not exist, and may span multiple
> physical interfaces in case of layerscape.

As far as i'm aware, the in kernel code always has a netdev for each
MAC. Are you talking about the vendor stack?

	Andrew