Thread (53 messages) 53 messages, 9 authors, 2023-01-30

Re: [PATCH v7 06/11] leds: trigger: netdev: add hardware control support

From: Christian Marangi <ansuelsmth@gmail.com>
Date: 2022-12-21 13:01:10
Also in: linux-devicetree, linux-doc, linux-leds, lkml

On Wed, Dec 21, 2022 at 09:54:43AM +0000, Russell King (Oracle) wrote:
On Wed, Dec 21, 2022 at 12:59:55AM +0100, Andrew Lunn wrote:
quoted
quoted
quoted
One thought on this approach though - if one has a PHY that supports
"activity" but not independent "rx" and "tx" activity indications
and it doesn't support software control, how would one enable activity
mode? There isn't a way to simultaneously enable both at the same
time... However, I need to check whether there are any PHYs that fall
into this category.
Problem is that for such feature and to have at least something working
we need to face compromise. We really can't support each switch feature
and have a generic API for everything.
I agree we need to make compromises. We cannot support every LED
feature of every PHY, they are simply too diverse. Hopefully we can
support some features of every PHY. In the worst case, a PHY simply
cannot be controlled via this method, which is the current state
today. So it is not worse off.
... and that compromise is that it's not going to be possible to enable
activity mode on 88e151x with how the code stands and with the
independent nature of "rx" and "tx" activity control currently in the
netdev trigger... making this whole approach somewhat useless for
Marvell PHYs.
Again we can consider adding an activity mode. It seems logical that
some switch may only support global traffic instead of independend tx or
rx... The feature are not mutually exclusive. One include the other 2.

We already a simple workaround for the link mode where on the current
driver, if the link mode is enabled just all rule for 10 100 and 1000
mbps are enabled simulating a global link event.
We really need to see a working implementation for this code for more
than just one PHY to prove that it is actually possible for it to
support other PHYs. If not, it isn't actually solving the problem,
and we're going to continue getting custom implementations to configure
the LED settings.
Agree that we need other user for this to catch some problem in the
implementation of this generic API.

-- 
	Ansuel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help