From: Christian Marangi <ansuelsmth@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Jonathan Corbet <corbet@lwn.net>, Pavel Machek <pavel@ucw.cz>,
Christian Marangi <ansuelsmth@gmail.com>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
John Crispin <john@phrozen.org>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-leds@vger.kernel.org, Tim Harvey <tharvey@gateworks.com>,
Alexander Stein <alexander.stein@ew.tq-group.com>,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Subject: [PATCH v7 00/11] Adds support for PHY LEDs with offload triggers
Date: Thu, 15 Dec 2022 00:54:27 +0100 [thread overview]
Message-ID: <20221214235438.30271-1-ansuelsmth@gmail.com> (raw)
This is another attempt on adding this feature on LEDs, hoping this is
the right time and someone finally notice this.
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 3 API (hw_control_status/start/stop).
They are used to put the LED in hardware mode and to configure the
various trigger.
- We have hardware triggers that are used to expose to userspace the
supported hardware mode and set the hardware mode on trigger
activation.
- We can also have triggers that both support hardware and software mode.
- The LED driver will declare each supported hardware blink mode and
communicate with the trigger all the supported blink modes that will
be available by sysfs.
- A trigger will use blink_set to configure the blink mode to active
in hardware mode.
- On hardware trigger activation, only the hardware mode is enabled but
the blink modes are not configured. The LED driver should reset any
link mode active by default.
Each LED driver will have to declare explicit support for the offload
trigger (or return not supported error code) as we the trigger_data 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.
The netdev trigger is expanded and it does now support hardware only
triggers.
The idea is to use hardware mode when a device_name is not defined.
An additional sysfs entry is added to give some info about the available
trigger modes supported in the current configuration.
It was reported that at least 3 other switch family would benefits by
this as they all lack support for a generic way to setup their leds and
netdev team NACK each try to add special code to support LEDs present
on switch in favor of a generic solution.
v7:
- Rebase on top of net-next (for qca8k changes)
- Fix some typo in commit description
- Fix qca8k leds documentation warning
- Remove RFC tag
v6:
- Back to RFC.
- Drop additional trigger
- Rework netdev trigger to support common modes used by switch and
hardware only triggers
- Refresh qca8k leds logic and driver
v5:
- Move out of RFC. (no comments from Andrew this is the right path?)
- Fix more spelling mistake (thx Randy)
- Fix error reported by kernel test bot
- Drop the additional HW_CONTROL flag. It does simplify CONFIG
handling and hw control should be available anyway to support
triggers as module.
v4:
- Rework implementation and drop hw_configure logic.
We now expand blink_set.
- Address even more spelling mistake. (thx a lot Randy)
- Drop blink option and use blink_set delay.
- Rework phy-activity trigger to actually make the groups dynamic.
v3:
- Rework start/stop as Andrew asked.
- Introduce more logic to permit a trigger to run in hardware mode.
- Add additional patch with netdev hardware support.
- Use test_bit API to check flag passed to hw_control_configure.
- Added a new cmd to hw_control_configure to reset any active blink_mode.
- Refactor all the patches to follow this new implementation.
v2:
- Fix spelling mistake (sorry)
- Drop patch 02 "permit to declare supported offload triggers".
Change the logic, now the LED driver declare support for them
using the configure_offload with the cmd TRIGGER_SUPPORTED.
- Rework code to follow this new implementation.
- Update Documentation to better describe how this offload
implementation work.
Christian Marangi (11):
leds: add support for hardware driven LEDs
leds: add function to configure hardware controlled LED
leds: trigger: netdev: drop NETDEV_LED_MODE_LINKUP from mode
leds: trigger: netdev: rename and expose NETDEV trigger enum modes
leds: trigger: netdev: convert device attr to macro
leds: trigger: netdev: add hardware control support
leds: trigger: netdev: use mutex instead of spinlocks
leds: trigger: netdev: add available mode sysfs attr
leds: trigger: netdev: add additional hardware only triggers
net: dsa: qca8k: add LEDs support
dt-bindings: net: dsa: qca8k: add LEDs definition example
.../devicetree/bindings/net/dsa/qca8k.yaml | 24 ++
Documentation/leds/leds-class.rst | 53 +++
drivers/leds/Kconfig | 11 +
drivers/leds/led-class.c | 27 ++
drivers/leds/led-triggers.c | 29 ++
drivers/leds/trigger/ledtrig-netdev.c | 385 ++++++++++++-----
drivers/net/dsa/qca/Kconfig | 9 +
drivers/net/dsa/qca/Makefile | 1 +
drivers/net/dsa/qca/qca8k-8xxx.c | 4 +
drivers/net/dsa/qca/qca8k-leds.c | 406 ++++++++++++++++++
drivers/net/dsa/qca/qca8k.h | 62 +++
include/linux/leds.h | 103 ++++-
12 files changed, 1015 insertions(+), 99 deletions(-)
create mode 100644 drivers/net/dsa/qca/qca8k-leds.c
--
2.37.2
next reply other threads:[~2022-12-14 23:58 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 23:54 Christian Marangi [this message]
2022-12-14 23:54 ` [PATCH v7 01/11] leds: add support for hardware driven LEDs Christian Marangi
2022-12-15 4:40 ` kernel test robot
2022-12-15 5:10 ` kernel test robot
2022-12-15 16:13 ` Russell King (Oracle)
2022-12-16 16:45 ` Christian Marangi
2022-12-16 16:51 ` Russell King (Oracle)
2022-12-20 23:35 ` Andrew Lunn
2023-01-03 5:40 ` Bagas Sanjaya
2022-12-14 23:54 ` [PATCH v7 02/11] leds: add function to configure hardware controlled LED Christian Marangi
2022-12-15 16:30 ` Russell King (Oracle)
2022-12-16 16:58 ` Christian Marangi
2022-12-14 23:54 ` [PATCH v7 03/11] leds: trigger: netdev: drop NETDEV_LED_MODE_LINKUP from mode Christian Marangi
2022-12-14 23:54 ` [PATCH v7 04/11] leds: trigger: netdev: rename and expose NETDEV trigger enum modes Christian Marangi
2022-12-20 23:48 ` Andrew Lunn
2022-12-14 23:54 ` [PATCH v7 05/11] leds: trigger: netdev: convert device attr to macro Christian Marangi
2022-12-14 23:54 ` [PATCH v7 06/11] leds: trigger: netdev: add hardware control support Christian Marangi
2022-12-15 5:31 ` kernel test robot
2022-12-15 15:27 ` Alexander Stein
2022-12-16 17:00 ` Christian Marangi
2023-01-02 12:44 ` Alexander Stein
2022-12-15 17:07 ` Russell King (Oracle)
2022-12-16 17:09 ` Christian Marangi
2022-12-20 23:59 ` Andrew Lunn
2022-12-21 9:54 ` Russell King (Oracle)
2022-12-21 13:00 ` Christian Marangi
2022-12-21 13:10 ` Andrew Lunn
2022-12-14 23:54 ` [PATCH v7 07/11] leds: trigger: netdev: use mutex instead of spinlocks Christian Marangi
2022-12-14 23:54 ` [PATCH v7 08/11] leds: trigger: netdev: add available mode sysfs attr Christian Marangi
2022-12-14 23:54 ` [PATCH v7 09/11] leds: trigger: netdev: add additional hardware only triggers Christian Marangi
2022-12-15 17:35 ` Russell King (Oracle)
2022-12-16 17:17 ` Christian Marangi
2022-12-21 0:12 ` Andrew Lunn
2022-12-21 12:56 ` Christian Marangi
2022-12-14 23:54 ` [PATCH v7 10/11] net: dsa: qca8k: add LEDs support Christian Marangi
2022-12-15 3:50 ` kernel test robot
2022-12-15 3:54 ` Arun.Ramadoss
2022-12-15 17:49 ` Russell King (Oracle)
2022-12-16 17:48 ` Christian Marangi
2022-12-20 23:11 ` Andrew Lunn
2022-12-14 23:54 ` [PATCH v7 11/11] dt-bindings: net: dsa: qca8k: add LEDs definition example Christian Marangi
2022-12-20 17:39 ` Rob Herring
2022-12-20 23:20 ` Andrew Lunn
2022-12-21 1:41 ` Andrew Lunn
2022-12-21 12:54 ` Christian Marangi
2022-12-21 12:59 ` Andrew Lunn
2022-12-21 15:29 ` Rob Herring
2023-01-29 20:43 ` Sander Vanheule
2023-01-29 22:02 ` Andrew Lunn
2023-01-30 10:59 ` Sander Vanheule
2023-01-30 13:48 ` Andrew Lunn
2022-12-20 23:23 ` Andrew Lunn
2022-12-15 15:34 ` [PATCH v7 00/11] Adds support for PHY LEDs with offload triggers Alexander Stein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221214235438.30271-1-ansuelsmth@gmail.com \
--to=ansuelsmth@gmail.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=andrew@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=john@phrozen.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=pavel@ucw.cz \
--cc=rasmus.villemoes@prevas.dk \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh+dt@kernel.org \
--cc=tharvey@gateworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).