linux-kernel - [PATCH RFC leds + net-next 0/3] Add support for LEDs on Marvell PHYs

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: <20200716171730.13227-1-marek.behun@nic.cz>
Date:   Thu, 16 Jul 2020 19:17:27 +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 0/3] Add support for LEDs on Marvell PHYs

Hello,

this RFC series should apply on both net-next/master and Pavel's
linux-leds/for-master tree.

This adds support for LED's connected to some Marvell PHYs.

LEDs are specified via device-tree. Example:

ethernet-phy@1 {
	reg = <1>;

	leds {
		led@0 {
			reg = <0>;
			color = <LED_COLOR_ID_GREEN>;
			function = LED_FUNCTION_LINK;
			linux,default-trigger = "hw:1000/100/10/nolink";
		};

		led@1 {
			reg = <1>;
			color = <LED_COLOR_ID_YELLOW>;
			function = LED_FUNCTION_ACTIVITY;
			linux,default-trigger = "hw:act/noact";
		};
	};
};

Since Marvell PHYs can control the LEDs themselves in various modes,
we need to be able to switch between them or disable them.

This is achieved by extending the LED trigger API with LED-private triggers.
The proposal for this is based on work by Ondrej and Pavel, but after writing
this support for Marvell PHYs I am not very happy how this turned out:
- this LED-private triggers API works by registering triggers with specific
  private trigger type. If this trigger type is defined for a trigger, only
  those LEDs will be able to set this trigger which also have this trigger type.
  (Both structs led_classdev and led_trigger have member trigger_type)
- on Marvell PHYs each LED can have up to 8 different triggers
- currently the driver supports up to 6 LEDs, since at least 88E1340 support
  6 LEDs
- almost every LED supports some mode which is not supported by at least one
  other LED
- this leads to the following dillema:
  1. either we support one trigger type across the driver, but then the
     /sys/class/leds/<LED>/trigger file will also list HW triggers not
     supported by this specific LED,
  2. or we add 6 trigger types, each different one LED, and register up to
     8 HW triggers for each trigger type, which results in up to 48 triggers
     per this driver.
  In this proposal alternative 1 is taken and when unsupported HW trigger
  is requested by writing to /sys/class/leds/<LED>/trigger file, the write
  system call returns -EOPNOTSUPP.
- therefore I think that this is not the correct way how to implement
  LED-private triggers, and instead an approach as desribed in [1].
  What do you people think?

Marek

Marek Behún (3):
  leds: trigger: add support for LED-private device triggers
  leds: trigger: return error value if .activate() failed
  net: phy: marvell: add support for PHY LEDs via LED class

 drivers/leds/led-triggers.c |  32 ++--
 drivers/net/phy/Kconfig     |   7 +
 drivers/net/phy/marvell.c   | 307 +++++++++++++++++++++++++++++++++++-
 include/linux/leds.h        |  10 ++
 4 files changed, 346 insertions(+), 10 deletions(-)

-- 
2.26.2