[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211107175718.9151-1-ansuelsmth@gmail.com>
Date: Sun, 7 Nov 2021 18:57:12 +0100
From: Ansuel Smith <ansuelsmth@...il.com>
To: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Jonathan Corbet <corbet@....net>, Pavel Machek <pavel@....cz>,
Ansuel Smith <ansuelsmth@...il.com>,
John Crispin <john@...ozen.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-leds@...r.kernel.org
Subject: [RFC PATCH 0/6] Adds support for PHY LEDs with offload triggers
This is another attempt in adding support for PHY LEDs. Most of the
times Switch/PHY have connected multiple LEDs that are controlled by HW
based on some rules/event. Currently we lack any support for a generic
way to control the HW part and normally we either never implement the
feature or only add control for brightness or hw blink.
This is based on Marek idea of providing some API to cled but use a
different implementation that in theory should be more generilized.
The current idea is:
- LED driver implement 2 API (trigger and configure). They are used to
put the LED in offload mode and to configure the various trigger.
- We have offload triggers that are used to expose to userspace the
supported offload triggers and set the offload mode on trigger
activation.
- The PHY will declare the supported offload triggers using the
linux,supported-offload-triggers binding in the dts.
- Only supported triggers from linux,supported-offload-triggers will be
exposed by the offload trigger to userspace via sysfs. Other won't be
configurable as they are not supported by the LED driver.
- The LED driver will set how the Offload mode is activated/disabled and
will set a configure function to set each supported offload triggers.
This function provide 3 different mode enable/disable/read that
will enable or disable the offload trigger or read the current status.
- On offload trigger activation, only the offload mode is triggered but
the offload triggers are not configured. This means that the LED will
run in offload mode but will have the default rules/event set by the
device by default. To change this the user will have to operate via
userspace (or we can consider adding another binding in the dts to
declare also a default trigger configuration)
Each LED driver will have to declare explicit support for the offload
trigger (or return not supported error code) as we pass a u32 flag that
the LED driver will elaborate and understand what is referring to (based
on the current active trigger).
I posted a user for this new implementation that will benefit from this
and will add a big feature to it. Currently qca8k can have up to 3 LEDs
connected to each PHY port and we have some device that have only one of
them connected and the default configuration won't work for that.
Ansuel Smith (5):
leds: permit to declare supported offload triggers
leds: add function to configure offload leds
leds: trigger: add offload-phy-activity trigger
net: dsa: qca8k: add LEDs support
dt-bindings: net: dsa: qca8k: add LEDs definition example
Marek BehĂșn (1):
leds: trigger: add API for HW offloading of triggers
.../devicetree/bindings/net/dsa/qca8k.yaml | 30 ++
Documentation/leds/leds-class.rst | 38 ++
drivers/leds/led-class.c | 15 +-
drivers/leds/led-triggers.c | 1 +
drivers/leds/trigger/Kconfig | 35 ++
drivers/leds/trigger/Makefile | 1 +
.../trigger/ledtrig-offload-phy-activity.c | 151 ++++++++
drivers/net/dsa/Kconfig | 9 +
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/qca8k-leds.c | 361 ++++++++++++++++++
drivers/net/dsa/qca8k.c | 4 +-
drivers/net/dsa/qca8k.h | 64 ++++
include/linux/leds.h | 76 ++++
13 files changed, 783 insertions(+), 3 deletions(-)
create mode 100644 drivers/leds/trigger/ledtrig-offload-phy-activity.c
create mode 100644 drivers/net/dsa/qca8k-leds.c
--
2.32.0
Powered by blists - more mailing lists