mbox series

[v6,0/6] Add a multicolor LED driver for groups of monochromatic LEDs

Message ID 20221117160447.294491-1-jjhiblot@traphandler.com
Headers show
Series Add a multicolor LED driver for groups of monochromatic LEDs | expand

Message

Jean-Jacques Hiblot Nov. 17, 2022, 4:04 p.m. UTC
Some HW design implement multicolor LEDs with several monochromatic LEDs.
Grouping the monochromatic LEDs allows to configure them in sync and use
the triggers.
The PWM multicolor LED driver implements such grouping but only for
PWM-based LEDs. As this feature is also desirable for the other types of
LEDs, this series implements it for any kind of LED device.

changes v5->v6:
 - restore sysfs access to the leds when the device is removed

changes v4->v5:
 - Use "depends on COMPILE_TEST || OF" in Kconfig to indicate that OF
   is a functional requirement, not just a requirement for the
   compilation.
 - in led_mcg_probe() check if devm_of_led_get_optional() returns an
   error before testing for the end of the list.
 - use sysfs_emit() instead of sprintf() in color_show().
 - some grammar fixes in the comments and the commit logs.

changes v2->v3, only minor changes:
 - rephrased the Kconfig descritpion
 - make the sysfs interface of underlying LEDs read-only only if the probe
   is successful.
 - sanitize the header files
 - removed the useless call to dev_set_drvdata()
 - use dev_fwnode() to get the fwnode to the device.

changes v1->v2:
 - Followed Rob Herrings's suggestion to make the dt binding much simpler.
 - Added a patch to store the color property of a LED in its class
   structure (struct led_classdev).


Jean-Jacques Hiblot (6):
  devres: provide devm_krealloc_array()
  leds: class: simplify the implementation of devm_of_led_get()
  leds: provide devm_of_led_get_optional()
  leds: class: store the color index in struct led_classdev
  dt-bindings: leds: Add binding for a multicolor group of LEDs
  leds: Add a multicolor LED driver to group monochromatic LEDs

 Documentation/ABI/testing/sysfs-class-led     |   9 +
 .../bindings/leds/leds-group-multicolor.yaml  |  64 +++++++
 drivers/leds/led-class.c                      |  65 +++++--
 drivers/leds/rgb/Kconfig                      |  10 ++
 drivers/leds/rgb/Makefile                     |   1 +
 drivers/leds/rgb/leds-group-multicolor.c      | 168 ++++++++++++++++++
 include/linux/device.h                        |  13 ++
 include/linux/leds.h                          |   3 +
 8 files changed, 319 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-group-multicolor.yaml
 create mode 100644 drivers/leds/rgb/leds-group-multicolor.c

Comments

Andy Shevchenko Nov. 17, 2022, 4:43 p.m. UTC | #1
On Thu, Nov 17, 2022 at 6:04 PM Jean-Jacques Hiblot
<jjhiblot@traphandler.com> wrote:
>
> This information might be useful for more than only deriving the led's
> name. And since we have this information, we can expose it in the sysfs.

...

> +What:          /sys/class/leds/<led>/color
> +Date:          October 2022
> +KernelVersion: 6.1

6.2

We missed v6.1. And I'm not sure with the current state of affairs
with LEDS subsystem maintenance we are not going to miss v6.2.
Jean-Jacques Hiblot Dec. 9, 2022, 5:33 p.m. UTC | #2
Hello Pavel,

I haven't had feedback on this series from the maintainers for some time 
now.

I understand that you're quite busy, but I'd appreciate if you could 
have a look at it.

Thanks,

Jean-Jacques
Lee Jones Dec. 23, 2022, 12:51 p.m. UTC | #3
On Fri, 09 Dec 2022, Jean-Jacques Hiblot wrote:

> Hello Pavel,
> 
> I haven't had feedback on this series from the maintainers for some time
> now.
> 
> I understand that you're quite busy, but I'd appreciate if you could have a
> look at it.

Not in my inbox.  Would you be kind enough to submit a [RESEND] please?
Jean-Jacques Hiblot Dec. 27, 2022, 9:47 a.m. UTC | #4
On 23/12/2022 13:51, Lee Jones wrote:
> On Fri, 09 Dec 2022, Jean-Jacques Hiblot wrote:
>
>> Hello Pavel,
>>
>> I haven't had feedback on this series from the maintainers for some time
>> now.
>>
>> I understand that you're quite busy, but I'd appreciate if you could have a
>> look at it.
> Not in my inbox.  Would you be kind enough to submit a [RESEND] please?

Certainly. I'll do it right away.

  Thanks

>