netdev - Re: [PATCH RFC net-next 2/6] net: phy: add support to set default rules

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] [day] [month] [year] [list]

Message-ID: <7d6fd4f6-3cc3-4a42-a726-6cbc4d902cc3@lunn.ch>
Date: Thu, 18 Dec 2025 11:12:52 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jijie Shao <shaojijie@...wei.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
	Frank.Sae@...or-comm.com, hkallweit1@...il.com,
	linux@...linux.org.uk, shenjian15@...wei.com,
	liuyonglong@...wei.com, chenhao418@...wei.com,
	jonathan.cameron@...wei.com, salil.mehta@...wei.com,
	shiyongbang@...wei.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC net-next 2/6] net: phy: add support to set default
 rules

On Thu, Dec 18, 2025 at 09:35:44AM +0800, Jijie Shao wrote:
> 
> on 2025/12/17 21:53, Andrew Lunn wrote:
> > > Some of our boards have only one LED, and we want to indicate both
> > > link and active(TX and RX) status simultaneously.
> > Configuration is generally policy, which is normally done in
> > userspace. I would suggest a udev rule.
> > 
> > 	Andrew
> 
> Yes, the PHY LED framework supports configuration from user space,
> allowing users to configure their preferred policies according to their own requirements.
> I believe this is the original intention of the LED framework.
> 
> However, we cannot require users to actively configure policies,
> nor can we restrict the types of OS versions they use.
> Therefore, I personally think that the driver should still provide a reasonable default policy
> to ensure that the LED behavior meets the needs of most scenarios.

The DT Maintainers are likely to push back if you add this to the DT
binding. You are not really describing the hardware.

In your case, it is the MAC driver which has access to the
configuration you want to use. So please think about how you can add
an API a MAC driver could use. It is not so easy, since the PHY led is
just a Linux LED. It can be used for anything, any trigger can be
assigned to it, like the heartbeat, CPU load, disc activity, etc. You
also need to look at keeping the state synchronised. The netdev
trigger will read the state of the LED when it is bound to the
LED. After that, it assumes it is controlling the LED. Any changes
which go direct to the LED will not be seen by the LED trigger.

	Andrew