Re: [PATCH 1/2] dt-bindings: leds: Document netdev trigger netdev-trigger-mode property

[Marek Vasut <marek.vasut@mailbox.org>]

On 8/9/25 6:29 PM, Andrew Lunn wrote:
>> as DT is supposed to be a hardware description, I think throwing arbitary
>> binary values around is not very readable - especially as the above would
>> be a combination of setting-bits for the TRIGGER_NETDEV_* things.
> 
> I tend to agree with you. This is a tricky area, since it does appear
> in most part to be configuration, not hardware.
> 
> What i think you should actually be describing is the label on the
> case next to the LED.
> 
> Taking a random example:
> 
> https://www.downloads.netgear.com/files/GDC/Unmanaged_Switches/GS105Pv3_GS105PPv3_GS108LP_GS108PP_GS116LP_GS116PP_DS.pdf
> 
> The case says:
> 
> Left LED: Link/ACT mode
> Green = Link at 1000M
> Yellow = Link at 10/100M
> Blink = ACT
> 
> Right: PoE Mode
> Green = Powered
> Yellow = Fault

This is meant to configure the netdev trigger, i.e. how Linux configures 
the PHY LED behavior (blink at 100/Full, not blink at 10/Full etc.), not 
the LED labels.

It is already possible to configure which trigger should be used for 
each LED in DT, it is also possible to configure trigger settings for 
some LED triggers in DT, but it is not possible to configure the netdev 
trigger in DT.

> So there is in fact four LEDs. Two of them are actually nothing to do
> with netdev. This shows how flexible 'PHY' LEDs are, they can in fact
> be used for anything. We currently don't have a PoE trigger, but it
> should not be too hard to add.
> 
> For the two actual netdev LEDs, we need to describe the text of the
> label. The naming of the DT property also needs to emphasise this is
> the label. And if the case has no label, you should not be putting
> properties in DT, the LEDs don't actually have any fixed meaning, it
> is user space policy to set them.
> 
> As you said, there has not been any obvious progress on such a DT
> binding for 6 months or more. I would probably interpret that as its
> not particularly important.

This is still in the backlog pipeline, which is too deep now, I'm sorry.

> Maybe it actually makes more sense to work
> on user space tools

The LEDs have to be configured before userspace is even started, that's 
what this patchset attempts to solve. Consider the state of the system 
before (proper) userspace that would configure the LEDs is even started, 
e.g. initramfs and other such edge cases. DT seems like the only place 
where this could be described, and it is done so for other LED triggers 
already.

Userspace configuration is solved by udev rules, that's not a problem.

-- 
Best regards,
Marek Vasut