netdev - Re: [net-next PATCH v4 10/14] dt-bindings: net: dsa: qca8k: add LEDs definition example

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 15:22:30 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Marek Behún <kabel@...nel.org>
Cc:     Christian Marangi <ansuelsmth@...il.com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Lee Jones <lee@...nel.org>, linux-leds@...r.kernel.org,
        pavel@....cz, 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>,
        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,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org
Subject: Re: [net-next PATCH v4 10/14] dt-bindings: net: dsa: qca8k: add LEDs
 definition example

> We could specify in DT something like:
>   eth0: ethernet-controller {
>     ...
>   }
> 
>   ethernet-phy {
>     leds {
>       led@0 {
>         reg = <0>;
>         color = <LED_COLOR_ID_GREEN>;
>         trigger-sources = <&eth0>;
>         function = LED_FUNCTION_ ?????? ;
>       }
>     }
>   }

For generic case, where you just have an LED on some random bus, you
need to know what netdev it should represent. And in effect, this
patch series gives you just that.

However, when we get to offload, which is the ultimate goal, things
are different. We cannot expect an LED inside the PHY connected to
eth42 to offload blinking for eth24. There is a clear hardware
relationship between the LED and the netdev. And in the more general
case, there will always be a hardware relationship, be it wifi
activity, or hard disk activity. phylib knows this relationship, and
the DSA core also knows this relationship. Probably the SATA core will
know the relationship. So i have a patchset which adds an op to the
cdev to ask it, what struct device do you HW blink for?
trigger-sources then becomes optional. And in fact, if it is used, you
need to verify if it fits to this relationship, and if not, refuse to
offload blinking, so software blinking only.

Anyway, that is an aside to your main question. But the Day Job is
calling. I will address your question later today.

	 Andrew