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]

Message-ID: <20230317084519.12d3587a@dellmb>
Date:   Fri, 17 Mar 2023 08:45:19 +0100
From:   Marek Behún <kabel@...nel.org>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        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, 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
  ...
These names are dependent on the order of classdev registration.

Marek