linux-kernel - Re: [net-next PATCH v4 04/14] net: phy: Add a binding for PHY LEDs

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:   Fri, 17 Mar 2023 14:55:11 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Marek Behún <kabel@...nel.org>
Cc:     Christian Marangi <ansuelsmth@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        John Crispin <john@...ozen.org>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, Lee Jones <lee@...nel.org>,
        linux-leds@...r.kernel.org
Subject: Re: [net-next PATCH v4 04/14] net: phy: Add a binding for PHY LEDs

On Fri, Mar 17, 2023 at 08:45:19AM +0100, Marek Behún wrote:
> On Fri, 17 Mar 2023 03:31:15 +0100
> Christian Marangi <ansuelsmth@...il.com> wrote:
> 
> > +	cdev->brightness_set_blocking = phy_led_set_brightness;
> > +	cdev->max_brightness = 1;
> > +	init_data.devicename = dev_name(&phydev->mdio.dev);
> > +	init_data.fwnode = of_fwnode_handle(led);
> > +
> > +	err = devm_led_classdev_register_ext(dev, cdev, &init_data);
> 
> Since init_data.devname_mandatory is false, devicename is ignored.
> Which is probably good, becuse the device name of a mdio device is
> often ugly, taken from devicetree or switch drivers, for example:
>   f1072004.mdio-mii
>   fixed-0
>   mv88e6xxx-1
> So either don't fill devicename or use devname_mandatory (and maybe
> fill devicename with something less ugly, but I guess if we don't have
> much choice if we want to keep persistent names).
> 
> Without devname_mandatory, the name of the LED classdev will be of the
> form
>   color:function[-function-enumerator],
> i.e.
>   green:lan
>   amber:lan-1
> 
> With multiple switch ethenret ports all having LAN function, it is
> worth noting that the function enumerator must be explicitly used in the
> devicetree, otherwise multiple LEDs will be registered under the same
> name, and the LED subsystem will add a number at the and of the name
> (function led_classdev_next_name), resulting in names
>   green:lan
>   green:lan_1
>   green:lan_2
>   ...

I'm testing on a Marvell RDK, with limited LEDs. It has one LED on the
front port to represent the WAN port. The DT patch is at the end of
the series. With that, i end up with:

root@...rd:/sys/class/leds# ls -l
total 0
lrwxrwxrwx 1 root root 0 Mar 17 01:10 f1072004.mdio-mii:00:WAN -> ../../devices/platform/soc/soc:interna
l-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/leds/f1072004.mdio-mii:00:WAN

I also have:

root@...rd:/sys/class/net/eth0/phydev/leds# ls
f1072004.mdio-mii:00:WAN

f1072004.mdio-mii:00: is not nice, but it is unique to a netdev. The
last part then comes from the label property. Since there is only one
LED, i went with what the port is intended to be used as. If there had
been more LEDs, i would of probably used labels like "LINK" and
"ACTIVITY", since that is often what they reset default
to. Alternatively, you could names the "Left" and "Right", which does
suggest they can be given any function.

I don't actually think the name is too important, so long as it is
unique. You are going to find it via /sys/class/net. MAC LEDs should
be /sys/class/net/eth42/leds, and PHY LEDs will be
/sys/class/net/phydev/leds.

It has been discussed in the past to either extend ethtool to
understand this, or write a new little tool to make it easier to
manipulate these LEDs.

	   Andrew