lkml.org 
[lkml]   [2023]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 00/13] Adds support for PHY LEDs with offload triggers
On Fri, Mar 10, 2023 at 10:37:25AM +0100, Linus Walleij wrote:
> On Thu, Mar 9, 2023 at 4:22 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > As to 'how a certain trigger on a certain LED is going to associate
> > itself with, say, a certain port' is clearly a property of the
> > hardware, when offloading is supported. I've not seen a switch you can
> > arbitrarily assign LEDs to ports. The Marvell switches have the LED
> > registers within the port registers, for example, two LEDs per port.
>
> Aha so there is an implicit HW dependency between the port and the
> LED, that we just cannot see in the device tree. Okay, it makes sense.

Well, i would say the dependency is in the device tree, in that the
LEDs are described in the ports, not as a block of their own at a
higher level within the switch. And in some switches, they might
actually be a block of registers in there own space, rather than in
the port registers. But i still expect there is a fixed mapping
between LED and port.

> I think there will be a day when a switch without LED controller appears,
> but the system has a few LEDs for the ports connected to an
> arbitrary GPIO controller, and then we will need this. But we have
> not seen that yet :)

The microchip sparx5 might be going in that direction. It has what
looks like a reasonably generic sgpio controller:
drivers/pinctrl/pinctrl-microchip-sgpio.c

But this not just about switches. It is also plain NICs. And using
ledtrig-netdev, you could make your keyboard LED blink based on
network traffic etc. So yes, using a phandle to an LED could very well
be useful in the future.

Andrew

\
 
 \ /
  Last update: 2023-03-27 00:53    [W:0.408 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site