linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5fb30bf-bf8d-417a-b031-8d706422bee0@huawei.com>
Date: Wed, 7 Jan 2026 17:40:44 +0800
From: Jijie Shao <shaojijie@...wei.com>
To: Andrew Lunn <andrew@...n.ch>
CC: <shaojijie@...wei.com>, <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 2025/12/18 18:12, Andrew Lunn wrote:
> 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.

Yes, a feasible approach is for the MAC driver to immediately
call `phydriver->led_hw_control_set()` after `phy_probe()` to configure this rule.
At this point, the netdev trigger for the LED has not yet been activated.

When the netdev trigger is activated, it will retrieve the initial state
from `phydriver->yt8521_led_hw_control_get()`, which is the rule we want to configure.

Thanks,
Jijie Shao