public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: lee@kernel.org, pavel@kernel.org
Cc: linux-kernel@vger.kernel.org, corbet@lwn.net,
	skhan@linuxfoundation.org, linux-leds@vger.kernel.org,
	linux-doc@vger.kernel.org, wse@tuxedocomputers.com,
	jacek.anaszewski@gmail.com, pobrn@protonmail.com,
	m.tretter@pengutronix.de
Subject: [PATCH 0/1] leds: Introduce the multi_max_intensity sysfs attribute
Date: Tue, 24 Mar 2026 21:27:50 +0100	[thread overview]
Message-ID: <20260324202751.6486-1-W_Armin@gmx.de> (raw)

This patch series was born out of of a mailing list thread [1] where
i asked how to properly model a RGB LED as a multicolor LED. Said
LED has some exotic properties:

1. 5 global brightness levels.
2. 50 intensity levels for each R/G/B color components.

The current sysfs interface mandates that the maximum intensity value
for each color component should be the same as the maximum global
brightness. This makes sense for LEDs that only emulate global
brightness using led_mc_calc_color_components(), but causes problems
for LEDs that perform global brightness control in hardware.

Faking a maximum global brightness of 50 will not work in this case,
as the hardware can change the global brightness on its own. Userspace
applications might also prefer to know the true maximum brightness
value.

Because of this i decided to add a new sysfs attribute called
"multi_max_intensity". This attribute is similar to the
"max_brightness" sysfs attribute, except that it targets the intensity
values inside the "multi_intensity" sysfs atribute. I also decided to 
cap intensity values comming from userspace to said maximum intensity
values to relieve drivers from doing it themself. This was already
proposed in a unrelated patch [2] and might break some misbehaving
userspace applications that do not respect max_brightness.

I tested the new sysfs attribute using a custom kernel module:

#include <linux/module.h>
#include <linux/init.h>
#include <linux/led-class-multicolor.h>

static int test_brightness_set_blocking(struct led_classdev *led_cdev,
					enum led_brightness brightness)
{
	struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(led_cdev);

	for (int i = 0; i < mc_cdev->num_colors; i++) {
		if (mc_cdev->subled_info[i].intensity > 30)
			return -EIO;
	}

	return 0;
}

static struct mc_subled subleds[] = {
	{
		.color_index = LED_COLOR_ID_RED,
		.max_intensity = 0,
		.channel = 1,
	},
	{
		.color_index = LED_COLOR_ID_GREEN,
		.max_intensity = 0,
		.channel = 2,
	},
	{
		.color_index = LED_COLOR_ID_BLUE,
		.max_intensity = 0,
		.channel = 3,
	},
};

static struct led_classdev_mc led_mc_cdev = {
	.led_cdev = {
		.max_brightness = 255,
		.color = LED_COLOR_ID_MULTI,
		.flags = LED_CORE_SUSPENDRESUME | LED_REJECT_NAME_CONFLICT,
		.brightness_set_blocking = test_brightness_set_blocking,
	},
	.num_colors = ARRAY_SIZE(subleds),
	.subled_info = subleds,
};

static int __init test_init(void)
{
	struct led_init_data init_data = {
		.devicename = "test-led",
		.default_label = "multicolor:" LED_FUNCTION_KBD_BACKLIGHT,
		.devname_mandatory = true,
	};

	return led_classdev_multicolor_register_ext(NULL, &led_mc_cdev, &init_data);
}
module_init(test_init);

static void __exit test_exit(void)
{
	led_classdev_multicolor_unregister(&led_mc_cdev);
}
module_exit(test_exit);

MODULE_AUTHOR("Armin Wolf <W_Armin@gmx.de>");
MODULE_DESCRIPTION("Multicolor LED test device");
MODULE_LICENSE("GPL");

[1] https://lore.kernel.org/linux-leds/2d91a44e-fce2-42dc-b529-133ab4a191f0@gmx.de/
[2] https://lore.kernel.org/linux-leds/20260123-leds-multicolor-limit-intensity-v1-1-b37761c2fdfd@pengutronix.de/

Changes since RFC:
- rework documentation
- drop useless defines
- reduce amount of driver code churn

Armin Wolf (1):
  leds: Introduce the multi_max_intensity sysfs attribute

 .../ABI/testing/sysfs-class-led-multicolor    | 19 ++++++--
 Documentation/leds/leds-class-multicolor.rst  | 21 ++++++++-
 drivers/leds/led-class-multicolor.c           | 47 ++++++++++++++++++-
 drivers/leds/leds-lp50xx.c                    |  1 +
 drivers/leds/rgb/leds-ncp5623.c               |  4 +-
 include/linux/led-class-multicolor.h          | 30 +++++++++++-
 6 files changed, 113 insertions(+), 9 deletions(-)

-- 
2.39.5


             reply	other threads:[~2026-03-24 20:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 20:27 Armin Wolf [this message]
2026-03-24 20:27 ` [PATCH 1/1] leds: Introduce the multi_max_intensity sysfs attribute Armin Wolf
2026-03-25  9:54   ` Werner Sembach
2026-03-25 20:41   ` Jacek Anaszewski
2026-03-31 10:38   ` Lee Jones
2026-03-31 19:17     ` Armin Wolf

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=20260324202751.6486-1-W_Armin@gmx.de \
    --to=w_armin@gmx.de \
    --cc=corbet@lwn.net \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=pavel@kernel.org \
    --cc=pobrn@protonmail.com \
    --cc=skhan@linuxfoundation.org \
    --cc=wse@tuxedocomputers.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