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  linux-cve-announce  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:   Tue, 10 Aug 2021 19:22:27 +0200
From:   Pavel Machek <pavel@....cz>
To:     Marek BehĂșn <kabel@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Florian Fainelli <f.fainelli@...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: Documentation for naming LEDs was Re: [PATCH net-next 5/5] igc:
 Export LEDs

Hi!

> > > The last time we discussed this (Andrew, Pavel and I), we've decided
> > > that for ethernet PHY controlled LEDs we want the devicename part
> > > should be something like
> > >    phyN  or  ethphyN  or  ethernet-phyN
> > > with N a number unique for every PHY (a simple atomically increased
> > > integer for every ethernet PHY).  
> > 
> > We might want to rethink this. PHYs typically have 2 or 3 LEDs. So we
> > want a way to indicate which LED of a PHY it is. So i suspect we will
> > want something like
> > 
> > ethphyN-led0, ethphyN-led1, ethphyN-led2.
> 
> But... there is still color and function and possibly function-numerator
> to differentiate them. I was talking only about the devicename part. So
> for three LEDs you can have, for example:
>   ethphyN:green:link
>   ethphyN:yellow:activity

For the record, this is the solution I'd like to see. Plus, we do want
it consistent between drivers, and I believe we need more than
list of functions provided by dt-bindings/leds/common.h -- we want
people to set something reasonable for "device" part, too.

Thus, I'm proposing this:

Rules will be simple -- when new type of LED is added to the
system, it will need to come with documentation explaining what the
LED does, and people will be expected to use existing names when
possible.

We'll also want to list "known bad" names in the file, so that there's
central place to search for aliases.

Thoughts?

Best regards,
								Pavel

--- /dev/null	2021-08-08 09:30:15.272028621 +0200
+++ Documentation/leds/well-known-leds.txt	2021-07-03 14:33:45.573718655 +0200
@@ -0,0 +1,57 @@
+-*- org -*-
+
+It is somehow important to provide consistent interface to the
+userland. LED devices have one problem there, and that is naming of
+directories in /sys/class/leds. It would be nice if userland would
+just know right "name" for given LED function, but situation got more
+complex.
+
+Anyway, if backwards compatibility is not an issue, new code should
+use one of the "good" names from this list, and you should extend the
+list where applicable.
+
+Bad names are listed, too; in case you are writing application that
+wants to use particular feature, you should probe for good name, first,
+but then try the bad ones, too.
+
+* Keyboards
+  
+Good: "input*:*:capslock"
+Good: "input*:*:scrolllock"
+Good: "input*:*:numlock"
+Bad: "shift-key-light" (Motorola Droid 4, capslock)
+
+Set of common keyboard LEDs, going back to PC AT or so.
+
+Good: "platform::kbd_backlight"
+Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads)
+Bad: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900)
+
+Frontlight/backlight of main keyboard.
+
+Bad: "button-backlight" (Motorola Droid 4)
+
+Some phones have touch buttons below screen; it is different from main
+keyboard. And this is their backlight.
+
+* Sound subsystem
+
+Good: "platform:*:mute"
+Good: "platform:*:micmute"
+
+LEDs on notebook body, indicating that sound input / output is muted.
+
+* System notification
+
+Good: "status-led:{red,green,blue}" (Motorola Droid 4)
+Bad: "lp5523:{r,g,b}" (Nokia N900)
+
+Phones usually have multi-color status LED.
+
+* Power management
+
+Good: "platform:*:charging" (allwinner sun50i)
+
+* Screen
+
+Good: ":backlight" (Motorola Droid 4)


-- 
http://www.livejournal.com/~pavelmachek

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ