Message-ID: <1bc46272-f26b-14a5-0139-a987b47a5814@solid-run.com>
Date:   Tue, 10 May 2022 11:56:06 +0300
From:   Josua Mayer <josua@...id-run.com>
To:     Andrew Lunn <andrew@...n.ch>
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


Am 09.05.22 um 15:49 schrieb Andrew Lunn:
> 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?
I am still struggling with the lower levels of networking terminology 
... so I was considering
when ethtool would report "Link detected: yes".
>   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.
I believe the intention was to decide later what information to visualize.
In this iteration there is one LED per sfp connector, with one colour.
But it is conceivable to in the future add more, and use them to 
indicate e.g. the negotiated speed (10/100/1000/10000).
> 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.

Found them. Those are a great pointer - I did not notice the 
trigger-sources property
while looking at led documentation and bindings,
but Documentation/devicetree/bindings/leds/common.yaml does have it.

So what his patch-set proposes covers a large part of my question here, 
thanks!

>> 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.
Okay. That will do for the immediate use-case.
>> 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.
Once the netdev (eth[0-9]+) has been created, all relations are known, yes.
And because you mentioned above that each MAC has a netdev, it will do.
E.g. while whatever we plug into the sfp connector changes, the MAC 
stays where it is - connected to a particular cage.
>
>> 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?
The coprocessor can be configured both at boot-time and runtime.
During runtime there is a vendor tool "restool" which can create and 
destroy network interfaces, which the dpaa2 driver knows to discover and 
bind to.

Your statement holds, quoting from the dpaa2 driver documentation:
"... exposes each switch port as a network interface, which can be 
included in a bridge or used as a standalone interface"

I made a false assumption here, Thank you!

> 	Andrew
sincerely
Josua Mayer

Powered by blists - more mailing lists