mbox series

[net-next,v4,00/13] leds: introduce new LED hw control APIs

Message ID 20230529163243.9555-1-ansuelsmth@gmail.com
Headers show
Series leds: introduce new LED hw control APIs | expand

Message

Christian Marangi May 29, 2023, 4:32 p.m. UTC
Since this series is cross subsystem between LED and netdev,
a stable branch was created to facilitate merging process.

This is based on top of branch ib-leds-netdev-v6.5 present here [1]
and rebased on top of net-next since the LED stable branch got merged.

This is a continue of [2]. It was decided to take a more gradual
approach to implement LEDs support for switch and phy starting with
basic support and then implementing the hw control part when we have all
the prereq done.

This is the main part of the series, the one that actually implement the
hw control API.

Some history about this feature and why
=======================================

This proposal is highly requested by the entire net community but the API
is not strictly designed for net usage but for a more generic usage.

Initial version were very flexible and designed to try to support every
aspect of the LED driver with many complex function that served multiple
purpose. There was an idea to have sw only and hw only LEDs and sw only
and hw only LEDs.

With some heads up from Andrew from the net mailing list, it was suggested
to implement a more basic yet easy to implement system.

These API strictly work with a designated trigger to offload their
function.
This may be confused with hw blink offload but LED may have an even more
advanced configuration where the entire aspect of the trigger is
offloaded and completely handled by the hardware.

An example of this usage are PHY or switch port LEDs. Almost every of
these kind of device have multiple LED attached and provide info of the
current port state.

Currently we lack any support of them but these device always provide a
way to configure them, from basic feature like turning the LED off or no
(implemented in previous series related to this feature) or even entirely
driven by the hw and power on/off/blink based on some events, like tx/rx
traffic, ethernet cable attached, link speed of 10mbps, 100mbps, 1000mbps
or more. They can also support multiple logic like blink with traffic only
if a particular link speed is attached. (an example of this is when a LED
is designated to be turned on only with 100mbps link speed and configured
to blink on traffic and a secondary LED of a different color is present to
serve the same function but only when the link speed is 1000mbps)

These case are very common for a PHY or a switch but they were never
standardized so OEM support all kind of variant and configuration.

Again with Andrew we compared some feature and we reached a common set
of modes that are for sure present in every kind of devices.

And this concludes history and why.

What is present in this series
==============================

This patch contain the required API to support this feature, I decided on
the name of hw control to quickly describe this feature.

I documented each require API in the related Documentation for leds-class
so I think it might me redundant to expose them here. Feel free to tell me
how to improve it if anything is not clear.

On an abstract idea, this feature require this:

    - The trigger needs to make use of it, this is currently implemented
      for the netdev trigger but other trigger can be expanded if the
      device expose these function. An idea might be a anything that
      handle a storage disk and have the LED configurable to blink when
      there is any activity to the disk.

    - The LED driver needs to expose and implement these new API.

Currently a LED driver supports only a trigger. The trigger should use
the related helper to check if the LED can be driven hy hardware.

The different modes a trigger support are exposed in the kernel include
leds.h header and are used by the LED driver to understand what to do.

Comments

Andrew Lunn May 29, 2023, 5:07 p.m. UTC | #1
On Mon, May 29, 2023 at 06:32:33PM +0200, Christian Marangi wrote:
> Document new Hardware driven LEDs APIs.
> 
> Some LEDs can be programmed to be driven by hardware. This is not
> limited to blink but also to turn off or on autonomously.
> To support this feature, a LED needs to implement various additional
> ops and needs to declare specific support for the supported triggers.
> 
> Add documentation for each required value and API to make hw control
> possible and implementable by both LEDs and triggers.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew
Jakub Kicinski May 30, 2023, 5:17 a.m. UTC | #2
On Mon, 29 May 2023 18:32:30 +0200 Christian Marangi wrote:
> Since this series is cross subsystem between LED and netdev,
> a stable branch was created to facilitate merging process.
> 
> This is based on top of branch ib-leds-netdev-v6.5 present here [1]
> and rebased on top of net-next since the LED stable branch got merged.
> 
> This is a continue of [2]. It was decided to take a more gradual
> approach to implement LEDs support for switch and phy starting with
> basic support and then implementing the hw control part when we have all
> the prereq done.
> 
> This is the main part of the series, the one that actually implement the
> hw control API.

Just to be 100% sure - these go into netdev/net-next directly, right?
No stable branch needed?
Andrew Lunn May 30, 2023, 12:54 p.m. UTC | #3
On Mon, May 29, 2023 at 10:17:22PM -0700, Jakub Kicinski wrote:
> On Mon, 29 May 2023 18:32:30 +0200 Christian Marangi wrote:
> > Since this series is cross subsystem between LED and netdev,
> > a stable branch was created to facilitate merging process.
> > 
> > This is based on top of branch ib-leds-netdev-v6.5 present here [1]
> > and rebased on top of net-next since the LED stable branch got merged.
> > 
> > This is a continue of [2]. It was decided to take a more gradual
> > approach to implement LEDs support for switch and phy starting with
> > basic support and then implementing the hw control part when we have all
> > the prereq done.
> > 
> > This is the main part of the series, the one that actually implement the
> > hw control API.
> 
> Just to be 100% sure - these go into netdev/net-next directly, right?
> No stable branch needed?
patchwork-bot+netdevbpf@kernel.org May 31, 2023, 9:10 a.m. UTC | #4
Hello:

This series was applied to netdev/net-next.git (main)
by David S. Miller <davem@davemloft.net>:

On Mon, 29 May 2023 18:32:30 +0200 you wrote:
> Since this series is cross subsystem between LED and netdev,
> a stable branch was created to facilitate merging process.
> 
> This is based on top of branch ib-leds-netdev-v6.5 present here [1]
> and rebased on top of net-next since the LED stable branch got merged.
> 
> This is a continue of [2]. It was decided to take a more gradual
> approach to implement LEDs support for switch and phy starting with
> basic support and then implementing the hw control part when we have all
> the prereq done.
> 
> [...]

Here is the summary with links:
  - [net-next,v4,01/13] leds: add APIs for LEDs hw control
    https://git.kernel.org/netdev/net-next/c/ed554d3f9451
  - [net-next,v4,02/13] leds: add API to get attached device for LED hw control
    https://git.kernel.org/netdev/net-next/c/052c38eb17e8
  - [net-next,v4,03/13] Documentation: leds: leds-class: Document new Hardware driven LEDs APIs
    https://git.kernel.org/netdev/net-next/c/8aa2fd7b6698
  - [net-next,v4,04/13] leds: trigger: netdev: refactor code setting device name
    https://git.kernel.org/netdev/net-next/c/28a6a2ef18ad
  - [net-next,v4,05/13] leds: trigger: netdev: introduce check for possible hw control
    https://git.kernel.org/netdev/net-next/c/4fd1b6d47a7a
  - [net-next,v4,06/13] leds: trigger: netdev: add basic check for hw control support
    https://git.kernel.org/netdev/net-next/c/6352f25f9fad
  - [net-next,v4,07/13] leds: trigger: netdev: reject interval store for hw_control
    https://git.kernel.org/netdev/net-next/c/c84c80c7388f
  - [net-next,v4,08/13] leds: trigger: netdev: add support for LED hw control
    https://git.kernel.org/netdev/net-next/c/7c145a34ba6e
  - [net-next,v4,09/13] leds: trigger: netdev: validate configured netdev
    https://git.kernel.org/netdev/net-next/c/33ec0b53beff
  - [net-next,v4,10/13] leds: trigger: netdev: init mode if hw control already active
    https://git.kernel.org/netdev/net-next/c/0316cc5629d1
  - [net-next,v4,11/13] leds: trigger: netdev: expose netdev trigger modes in linux include
    https://git.kernel.org/netdev/net-next/c/947acacab5ea
  - [net-next,v4,12/13] net: dsa: qca8k: implement hw_control ops
    https://git.kernel.org/netdev/net-next/c/e0256648c831
  - [net-next,v4,13/13] net: dsa: qca8k: add op to get ports netdev
    https://git.kernel.org/netdev/net-next/c/4f53c27f772e

You are awesome, thank you!
Lee Jones May 31, 2023, 10:46 a.m. UTC | #5
On Wed, 31 May 2023, patchwork-bot+netdevbpf@kernel.org wrote:

> Hello:
> 
> This series was applied to netdev/net-next.git (main)
> by David S. Miller <davem@davemloft.net>:

*sigh*
 
> On Mon, 29 May 2023 18:32:30 +0200 you wrote:
> > Since this series is cross subsystem between LED and netdev,
> > a stable branch was created to facilitate merging process.
> > 
> > This is based on top of branch ib-leds-netdev-v6.5 present here [1]
> > and rebased on top of net-next since the LED stable branch got merged.
> > 
> > This is a continue of [2]. It was decided to take a more gradual
> > approach to implement LEDs support for switch and phy starting with
> > basic support and then implementing the hw control part when we have all
> > the prereq done.
> > 
> > [...]
> 
> Here is the summary with links:
>   - [net-next,v4,01/13] leds: add APIs for LEDs hw control
>     https://git.kernel.org/netdev/net-next/c/ed554d3f9451
>   - [net-next,v4,02/13] leds: add API to get attached device for LED hw control
>     https://git.kernel.org/netdev/net-next/c/052c38eb17e8
>   - [net-next,v4,03/13] Documentation: leds: leds-class: Document new Hardware driven LEDs APIs
>     https://git.kernel.org/netdev/net-next/c/8aa2fd7b6698
>   - [net-next,v4,04/13] leds: trigger: netdev: refactor code setting device name
>     https://git.kernel.org/netdev/net-next/c/28a6a2ef18ad
>   - [net-next,v4,05/13] leds: trigger: netdev: introduce check for possible hw control
>     https://git.kernel.org/netdev/net-next/c/4fd1b6d47a7a
>   - [net-next,v4,06/13] leds: trigger: netdev: add basic check for hw control support
>     https://git.kernel.org/netdev/net-next/c/6352f25f9fad
>   - [net-next,v4,07/13] leds: trigger: netdev: reject interval store for hw_control
>     https://git.kernel.org/netdev/net-next/c/c84c80c7388f
>   - [net-next,v4,08/13] leds: trigger: netdev: add support for LED hw control
>     https://git.kernel.org/netdev/net-next/c/7c145a34ba6e
>   - [net-next,v4,09/13] leds: trigger: netdev: validate configured netdev
>     https://git.kernel.org/netdev/net-next/c/33ec0b53beff
>   - [net-next,v4,10/13] leds: trigger: netdev: init mode if hw control already active
>     https://git.kernel.org/netdev/net-next/c/0316cc5629d1
>   - [net-next,v4,11/13] leds: trigger: netdev: expose netdev trigger modes in linux include
>     https://git.kernel.org/netdev/net-next/c/947acacab5ea
>   - [net-next,v4,12/13] net: dsa: qca8k: implement hw_control ops
>     https://git.kernel.org/netdev/net-next/c/e0256648c831
>   - [net-next,v4,13/13] net: dsa: qca8k: add op to get ports netdev
>     https://git.kernel.org/netdev/net-next/c/4f53c27f772e
> 
> You are awesome, thank you!
> -- 
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html
> 
>