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-next>] [day] [month] [year] [list]
Message-Id: <20200723181319.15988-1-marek.behun@nic.cz>
Date:   Thu, 23 Jul 2020 20:13:18 +0200
From:   Marek Behún <marek.behun@....cz>
To:     linux-leds@...r.kernel.org
Cc:     Pavel Machek <pavel@....cz>, jacek.anaszewski@...il.com,
        Dan Murphy <dmurphy@...com>,
        Ondřej Jirman <megous@...ous.com>,
        netdev@...r.kernel.org, Russell King <linux@...linux.org.uk>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>, linux-kernel@...r.kernel.org,
        Marek Behún <marek.behun@....cz>
Subject: [PATCH RFC leds + net-next v2 0/1] Add support for LEDs on Marvell PHYs

Hi,

this is v2 of my RFC adding support for LEDs connected to Marvell PHYs.

The LED subsystem patches are not contained:
- the patch adding support for LED private triggers is already accepted
  in Pavel Machek's for-next tree.
  If you want to try this patch on top of net-next, please also apply
  https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/commit/?h=for-next&id=93690cdf3060c61dfce813121d0bfc055e7fa30d
- the other led-trigger patch is not needed in this version of the RFC

The main difference from v1 is that only one trigger, named
"hw-control", is added to the /sys/class/leds/<LED>/trigger file.

When this trigger is activated, another file called "hw_control" is
created in the /sys/class/leds/<LED>/ directory. This file lists
available HW control modes for this LED in the same way the trigger
file does for triggers.

Example:

  # cd /sys/class/leds/eth0\:green\:link/
  # cat trigger
  [none] hw-control timer oneshot heartbeat ...
  # echo hw-control >trigger
  # cat trigger
  none [hw-control] timer oneshot heartbeat ...
  # cat hw_control
  link/nolink link/act/nolink 1000/100/10/nolink act/noact
  blink-act/noact transmit/notransmit copperlink/else [1000/else]
  force-hi-z force-blink
  # echo 1000/100/10/nolink >hw_control
  # cat hw_control
  link/nolink link/act/nolink [1000/100/10/nolink] act/noact
  blink-act/noact transmit/notransmit copperlink/else 1000/else
  force-hi-z force-blink

The benefit here is that only one trigger is registered via LED API.
I guess there are other PHY drivers which too support HW controlled
blinking modes. So of this way of controlling PHY LED HW controlled
modes is accepted, the code creating the hw-control trigger and
hw_control file should be made into library code so that it can be
reused.

What do you think?

Marek

Marek Behún (1):
  net: phy: marvell: add support for PHY LEDs via LED class

 drivers/net/phy/Kconfig   |   7 +
 drivers/net/phy/marvell.c | 423 +++++++++++++++++++++++++++++++++++++-
 2 files changed, 429 insertions(+), 1 deletion(-)

-- 
2.26.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ