netdev - Re: [PATCH] leds: trigger: netdev: Check offload ability on interface up

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: <dcad968d-b305-4c0a-b377-1a147d156756@denx.de>
Date: Thu, 3 Oct 2024 14:15:05 +0200
From: Marek Vasut <marex@...x.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: linux-leds@...r.kernel.org,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Christian Marangi <ansuelsmth@...il.com>,
 Christophe Roullier <christophe.roullier@...s.st.com>,
 Daniel Golle <daniel@...rotopia.org>, Heiner Kallweit
 <hkallweit1@...il.com>, Lee Jones <lee@...nel.org>,
 Lukasz Majewski <lukma@...x.de>, Pavel Machek <pavel@....cz>,
 kernel@...electronics.com, linux-stm32@...md-mailman.stormreply.com,
 netdev@...r.kernel.org
Subject: Re: [PATCH] leds: trigger: netdev: Check offload ability on interface
 up

On 10/3/24 2:05 PM, Andrew Lunn wrote:
>>> Nice use of udev. I had not thought about using it for this.
> 
>> Is there some other way to configure the netdev-triggered PHY LEDs ?
>> I still feel the udev rule is somewhat brittle and fragile, and also not
>> available early enough for default PHY LED configuration, i.e. the LEDs are
>> not blinking when I use e.g. ip=/nfsroot= when booting from NFS root until
>> the userspace started, which is not nice. The only alternative I can imagine
>> is default configuration in DT, which was already rejected a few years ago.
> 
> Device tree is the only early way i can think of, especially for NFS
> root.
> 
> What has clearly been rejected is each vendor having their own DT
> binding. But i think we might have more success with one generic
> binding for all MAC/PHY LEDs.

Right now I have this (for one of the PHY LEDs):

led@0 {
         reg = <0>;
         color = <LED_COLOR_ID_GREEN>;
         function = LED_FUNCTION_WAN;
         linux,default-trigger = "netdev";
};

What about be useful is to set the link_10/100/1000 and rx/tx flags here 
somehow. It cannot be 'function' because that is already used to define 
the port purpose.

Maybe something like 'led-pattern' property used by 'pattern' trigger 
would work ? Some sort of "led-netdev-flags = LINK10 | LINK100;" ?

> The way i was thinking about it, was to describe the label on the
> front panel. That is hardware you are describing, so fits DT.
> 
> We are clearly in the grey area for DT, so i can understand some push
> back on this from the DT Maintainers.

It would be a policy, yes.