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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 May 2022 14:49:59 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Josua Mayer <josua@...id-run.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH RFC] net: sfp: support assigning status LEDs to SFP
 connectors

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