Date:   Fri, 17 Mar 2023 15:22:30 +0100
From:   Andrew Lunn <andrew@lunn.ch>
To:     Marek =?iso-8859-1?Q?Beh=FAn?= <kabel@kernel.org>
Cc:     Christian Marangi <ansuelsmth@gmail.com>,
        Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org,
        Lee Jones <lee@kernel.org>, linux-leds@vger.kernel.org,
        pavel@ucw.cz, Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        Gregory Clement <gregory.clement@bootlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        John Crispin <john@phrozen.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-arm-msm@vger.kernel.org
Subject: Re: [net-next PATCH v4 10/14] dt-bindings: net: dsa: qca8k: add LEDs
 definition example
Message-ID: <8825d43d-7340-4984-8c13-25731edbd827@lunn.ch>
References: <20230317023125.486-1-ansuelsmth@gmail.com>
 <20230317023125.486-11-ansuelsmth@gmail.com>
 <20230317091410.58787646@dellmb>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230317091410.58787646@dellmb>
Precedence: bulk

> 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