[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c82f4e1-0702-4617-b40c-d7f1cbd5a1de@huawei.com>
Date: Thu, 18 Dec 2025 09:35: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/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.
Thanks!
Jijie Shao
Powered by blists - more mailing lists