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@xxxxxxxxxxxxxxx> > > > > Add led trigger implemented with config-symbol LEDS_TRIGGER_NETDEV to > > binding. > > > > Signed-off-by: Frank Wunderlich <frank-w@xxxxxxxxxxxxxxx> > > --- > > 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.
