From: Bernhard Nortmann <bernhard.nortmann@web.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] allow LED initialization without STATUS_LED_BOOT
Date: Sat, 28 Mar 2015 17:40:54 +0100 [thread overview]
Message-ID: <5516D996.4050001@web.de> (raw)
For current U-Boot to initialize status LEDs via status_led_init(), it
is required to have both CONFIG_STATUS_LED and STATUS_LED_BOOT defined.
This may be a particular concern with GPIO LEDs, where __led_init() is
required to correctly set up the GPIO (gpio_request and
gpio_direction_output). Without STATUS_LED_BOOT the initialization isn't
called, which could leave the user with a non-functional "led" command -
due to the fact that the LED routines in gpio_led.c use gpio_set_value()
just fine, but the GPIO never got set up properly in the first place.
I think having CONFIG_STATUS_LED is sufficient to justify a
corresponding call to status_led_init(), even with no STATUS_LED_BOOT
defined. To do so, common/board_r.c needs some way to call that routine
either directly (which probably requires exposing it via status_led.h)
or indirectly. For the latter, I've attached a patch that (ab)uses an
invalid LED id in status_led_set() to enforce the init.
Regards, B. Nortmann
---
common/board_r.c | 10 +++++++---
drivers/misc/status_led.c | 7 ++++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c
index 0335f6b..c67f459 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -547,11 +547,15 @@ static int initr_kgdb(void)
}
#endif
-#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+#ifdef CONFIG_STATUS_LED
static int initr_status_led(void)
{
+#ifdef STATUS_LED_BOOT
status_led_set(STATUS_LED_BOOT, STATUS_LED_BLINKING);
-
+#else
+ /* use invalid LED id to enforce status_led_init() */
+ status_led_set(-1, 0);
+#endif
return 0;
}
#endif
@@ -838,7 +842,7 @@ init_fnc_t init_sequence_r[] = {
|| defined(CONFIG_M68K)
timer_init, /* initialize timer */
#endif
-#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+#ifdef CONFIG_STATUS_LED
initr_status_led,
#endif
/* PPC has a udelay(20) here dating from 2002. Why? */
diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c
index ed9adb2..4751c8d 100644
--- a/drivers/misc/status_led.c
+++ b/drivers/misc/status_led.c
@@ -94,12 +94,13 @@ void status_led_set (int led, int state)
{
led_dev_t *ld;
- if (led < 0 || led >= MAX_LED_DEV)
- return;
-
+ /* reordered, allows using invalid led ID to enforce init */
if (!status_led_init_done)
status_led_init ();
+ if (led < 0 || led >= MAX_LED_DEV)
+ return;
+
ld = &led_dev[led];
ld->state = state;
--
2.0.5
reply other threads:[~2015-03-28 16:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=5516D996.4050001@web.de \
--to=bernhard.nortmann@web.de \
--cc=u-boot@lists.denx.de \
/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.