lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 22 Jul 2021 04:19:08 +0200
From:   Marek BehĂșn <kabel@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Pavel Machek <pavel@....cz>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
        kuba@...nel.org, Kurt Kanzenbach <kurt@...utronix.de>,
        netdev@...r.kernel.org, sasha.neftin@...el.com,
        vitaly.lifshits@...el.com, vinicius.gomes@...el.com,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Dvora Fuxbrumer <dvorax.fuxbrumer@...ux.intel.com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

On Thu, 22 Jul 2021 03:45:21 +0200
Andrew Lunn <andrew@...n.ch> 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

Powered by blists - more mailing lists