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

[Jijie Shao]

on 2026/1/7 21:09, 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.
> As i said, DT describes hardware, the fact there is an LED, what bus
> it is on, colour etc, is describing hardware. How you blink it is
> policy, so i expect the DT Maintainers will push back on putting
> policy into DT.
>
> So i think your best way forwards is as Russell suggests, some form of
> firmware sets the LED before Linux takes control of it. Or udev.
>
> 	Andrew

Yes, at present, this seems to be the only solution.
Recently, I have also been developing a UEFI driver for PXE,
which might be a solution.

However, there is no way to handle the issue with another patch;
I cannot directly modify the ACPI table (a risky operation).

Thanks,
Jijie Shao