Re: [PATCH net-next 5/5] igc: Export LEDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 22 Jul 2021 03:45:21 +0200
Andrew Lunn <andrew@xxxxxxx> wrote:

> On Thu, Jul 22, 2021 at 12:45:06AM +0200, Pavel Machek wrote:
> > Hi!
> >   
> > > Also, function is totally unclear. The whole reason we want to use
> > > Linux LEDs is triggers, and it is the selected trigger which
> > > determines the function.  
> > 
> > Usually, yes. But "function" is what _manufacturer_ wanted LED to
> > mean  
> 
> So you are saying the function should be the reset default of the PHY,
> or MAC?

Pavel is talking about the manufacturer of the whole device, not just
the controller. For example on Turris Omnia there are icons over the
LEDs indicating their function. There are other devices, for example
ethernet switches, with LEDs dedicated to indicate specific things, and
these do not necessarily have to be the same as the LED controller
default.

Of course the problem is that we are not always able to determine this
from kernel. In the case of ethernet PHYs I would not create LED
classdevs unless they are defined in DTS/ACPI. In the case of igc
I am not exactly sure if the driver should register these LEDs. What if
they the manufacturer did not connected LEDs to all 3 pins, but only 1,
for example? Or used the LED pin for some other funtion, like GPIO (if
igc supports it)? Do we want to create LED classdevs for potentially
nonexistent LEDs? If yes, then I guess the function should be the reset
default.

Marek



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux