[RFC v1 1/5] dt-bindings: leds: add led trigger netdev

[Daniel Golle]

On Mon, May 06, 2024 at 10:18:09AM +0200, Krzysztof Kozlowski wrote:
> On 05/05/2024 18:45, Frank Wunderlich wrote:
> > From: Frank Wunderlich <frank-w at public-files.de>
> > 
> > Add led trigger implemented with config-symbol LEDS_TRIGGER_NETDEV to
> > binding.
> > 
> > Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
> > ---
> >  Documentation/devicetree/bindings/leds/common.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> > index 8a3c2398b10c..bf9a101e4d42 100644
> > --- a/Documentation/devicetree/bindings/leds/common.yaml
> > +++ b/Documentation/devicetree/bindings/leds/common.yaml
> > @@ -113,6 +113,8 @@ properties:
> >              # LED indicates NAND memory activity (deprecated),
> >              # in new implementations use "mtd"
> >            - nand-disk
> > +            # LED indicates network activity
> > +          - netdev
> 
> "dev" is redundant (there is no flash-dev or usb-host-dev). Two network
> interfaces are already provided, so your commit msg must provide
> rationale why this is not enough and why this is useful/needed.

Also note that using 'netdev' assigned via DT via linux,default-trigger
currently doesn't work well. This is because the assignment of the trigger
from DT happens when the PHY is being attached initially, and that's
**before** the network device is registered with Linux.
As a result, LED event offloading is never used if done in this way.

I know that bindings and implementation are two different independent
things, but yet I believe that adding bindings for a feature which doesn't
really work would be misleading.