From: Christian Marangi <ansuelsmth@gmail.com>
To: Tom Rini <trini@konsulko.com>,
Joe Hershberger <joe.hershberger@ni.com>,
Ramon Fried <rfried.dev@gmail.com>,
Christian Marangi <ansuelsmth@gmail.com>,
Dario Binacchi <dario.binacchi@amarulasolutions.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Arseniy Krasnov <avkrasnov@salutedevices.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Dmitry Dunaev <dunaev@tecon.ru>, Simon Glass <sjg@chromium.org>,
Devarsh Thakkar <devarsht@ti.com>, Bin Meng <bmeng.cn@gmail.com>,
Nikhil M Jain <n-jain1@ti.com>,
Shiji Yang <yangshiji66@outlook.com>,
Raymond Mao <raymond.mao@linaro.org>,
Leo Yu-Chi Liang <ycliang@andestech.com>,
Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
Doug Zobel <douglas.zobel@climate.com>,
u-boot@lists.denx.de, John Crispin <john@phrozen.org>
Subject: [PATCH v4 1/9] misc: gpio_led: fix broken coloured LED status functions
Date: Thu, 20 Jun 2024 01:03:19 +0200 [thread overview]
Message-ID: <20240619230400.8459-2-ansuelsmth@gmail.com> (raw)
In-Reply-To: <20240619230400.8459-1-ansuelsmth@gmail.com>
The GPIO LED driver is a backend to provide LED status functions via the
GPIO common functions.
The coloured LED functions are currently broken and deviates from what
is written in README.LED
Quoting the README.LED:
CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors.
This must be a valid LED number (0-5). Other similar color LED's macros
are CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and
CONFIG_STATUS_LED_BLUE.
Hence the value of the config must refer to the ID.
Currently this is not the case and the driver expect the GPIO ID to be
put in these config. On top of this to actually have these functions, a
never define in Kconfig config must be declared to actually compile
them. (CONFIG_GPIO_LED_STUBS)
To fix this and the GPIO problem, introduce some define that reference
the LED_STATUS_BIT<n> config to have the ID->BIT connection (as
described in Docs) and drop the never defined config.
The gpio_led already provide a wrapper to the functions and should not
be enabled if the board provide their custom function hence it's ok to
also provide the wrapper for the colour functions.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/misc/gpio_led.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index e63689967a7..6626b137087 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -51,56 +51,63 @@ void __led_toggle(led_id_t mask)
gpio_set_value(mask, !gpio_get_value(mask));
}
-#ifdef CONFIG_GPIO_LED_STUBS
-
/* 'generic' override of colored LED stubs, to use GPIO functions instead */
+/* We support up to 6 LEDs, LED 0 STATUS BIT doesn't have the number suffix */
+#define GPIO_BIT0 CONFIG_LED_STATUS_BIT
+#define GPIO_BIT1 CONFIG_LED_STATUS_BIT1
+#define GPIO_BIT2 CONFIG_LED_STATUS_BIT2
+#define GPIO_BIT3 CONFIG_LED_STATUS_BIT3
+#define GPIO_BIT4 CONFIG_LED_STATUS_BIT4
+#define GPIO_BIT5 CONFIG_LED_STATUS_BIT5
+/* C preprocessor magic way to generate a GPIO_LED<id> reference */
+#define GPIO_BIT(id) ___PASTE(GPIO_BIT, id)
+
#ifdef CONFIG_LED_STATUS_RED
+
void red_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_RED), CONFIG_LED_STATUS_ON);
}
void red_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_RED), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_GREEN
void green_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_GREEN), CONFIG_LED_STATUS_ON);
}
void green_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_GREEN), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_YELLOW
void yellow_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_YELLOW), CONFIG_LED_STATUS_ON);
}
void yellow_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_YELLOW), CONFIG_LED_STATUS_OFF);
}
#endif
#ifdef CONFIG_LED_STATUS_BLUE
void blue_led_on(void)
{
- __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_ON);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_ON);
}
void blue_led_off(void)
{
- __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_OFF);
+ __led_set(GPIO_BIT(CONFIG_LED_STATUS_BLUE), CONFIG_LED_STATUS_OFF);
}
#endif
-
-#endif /* CONFIG_GPIO_LED_STUBS */
--
2.43.0
next prev parent reply other threads:[~2024-06-20 1:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 23:03 [PATCH v4 0/9] misc: introduce STATUS LED activity function Christian Marangi
2024-06-19 23:03 ` Christian Marangi [this message]
2024-06-19 23:03 ` [PATCH v4 2/9] led: status_led: add support for white LED colour Christian Marangi
2024-06-19 23:03 ` [PATCH v4 3/9] led: status_led: add function to toggle a status LED Christian Marangi
2024-06-19 23:03 ` [PATCH v4 4/9] led: status_led: add warning when an invalid Status LED ID is used Christian Marangi
2024-06-20 17:31 ` Peter Robinson
2024-06-19 23:03 ` [PATCH v4 5/9] led: status_led: add new activity LED config and functions Christian Marangi
2024-06-19 23:03 ` [PATCH v4 6/9] tftp: implement support for LED status activity Christian Marangi
2024-06-19 23:03 ` [PATCH v4 7/9] mtd: " Christian Marangi
2024-06-19 23:03 ` [PATCH v4 8/9] ubi: " Christian Marangi
2024-06-19 23:03 ` [PATCH v4 9/9] doc: convert README.LED to .rst documentation Christian Marangi
2024-06-20 6:13 ` Heinrich Schuchardt
2024-06-20 4:37 ` Christian Marangi
2024-06-20 17:11 ` Heinrich Schuchardt
2024-06-20 6:34 ` [PATCH v4 0/9] misc: introduce STATUS LED activity function Heinrich Schuchardt
2024-06-20 4:29 ` Christian Marangi
2024-06-20 16:55 ` Tom Rini
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=20240619230400.8459-2-ansuelsmth@gmail.com \
--to=ansuelsmth@gmail.com \
--cc=avkrasnov@salutedevices.com \
--cc=bmeng.cn@gmail.com \
--cc=dario.binacchi@amarulasolutions.com \
--cc=devarsht@ti.com \
--cc=douglas.zobel@climate.com \
--cc=dunaev@tecon.ru \
--cc=joe.hershberger@ni.com \
--cc=john@phrozen.org \
--cc=miquel.raynal@bootlin.com \
--cc=n-jain1@ti.com \
--cc=rasmus.villemoes@prevas.dk \
--cc=raymond.mao@linaro.org \
--cc=rfried.dev@gmail.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
--cc=yangshiji66@outlook.com \
--cc=ycliang@andestech.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.