From: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 6/7] status_led: Add support for inverted LEDs
Date: Sun, 29 Sep 2013 15:40:10 +0200 (CEST) [thread overview]
Message-ID: <1799293256.2243041.1380462010404.JavaMail.zimbra@advansee.com> (raw)
In-Reply-To: <CAP9ODKpQL1Z0ad4nmgfCeasHAvUru9WbNpDO8tWs0F5aJnhkew@mail.gmail.com>
Hi Otavio,
On Saturday, September 28, 2013 9:08:48 PM, Otavio Salvador wrote:
> On Sat, Sep 28, 2013 at 1:49 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Sat, Sep 28, 2013 at 11:17 AM, Beno?t Th?baudeau
> > <benoit.thebaudeau@advansee.com> wrote:
> >> Dear Otavio Salvador,
> >>
> >> On Saturday, September 28, 2013 5:24:17 AM, Otavio Salvador wrote:
> >>> There're cases we want to use active-low LEDs and the 'inverted' logic
> >>> needs to be added. This includes it using the STATUS_LED_INVERT macro.
> >>
> >> There is already a STATUS_LED_ACTIVE definition (though not one per LED)
> >> in
> >> include/status_led.h for some platforms. Wouldn't it be worth keeping the
> >> same
> >> naming here for consistency (i.e. STATUS_LED_ACTIVEn, which would also
> >> imply
> >> exchanging 0/1 values)?
> >
> > I agree. "INVERT" is confusing, because we don't know what is the normal
> > state.
> >
> > Doing like Beno?t suggests would be clearer: STATUS_LED_ACTIVE0 or
> > STATUS_LED_ACTIVE1.
>
> The problem here is that the BIT LEDs are used in the cmd_led and it
> does not have the 'active' knowledge but a ON OFF concept. So what we
> do there is to change the intended status. The STATUS_LED_ACTIVE is
> for the STATUS_LED_BOOT and not for a 'specific' bit.
I meant that the current use of STATUS_LED_ACTIVE could be extended to what you
are trying to do here:
+#ifndef STATUS_LED_ACTIVE
+#define STATUS_LED_ACTIVE 1
+#endif
+#ifndef STATUS_LED_ACTIVE1
+#define STATUS_LED_ACTIVE1 1
+#endif
+#ifndef STATUS_LED_ACTIVE2
+#define STATUS_LED_ACTIVE2 1
+#endif
+#ifndef STATUS_LED_ACTIVE3
+#define STATUS_LED_ACTIVE3 1
+#endif
But then, maybe it's not the call to __led_set() that should be changed, but
rather how the passed value is used in the underlying layer, e.g. in
drivers/misc/gpio_led.c. However, since the status LED API takes binary states,
it better fits in drivers/misc/status_led.c as you did.
That means that __led_set() would no longer take STATUS_LED_ON/OFF, but rather
something like STATUS_LED_HI/LO, and led_state_value() would convert
STATUS_LED_ON/OFF to STATUS_LED_HI/LO according to STATUS_LED_ACTIVEn.
Best regards,
Beno?t
next prev parent reply other threads:[~2013-09-29 13:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-28 3:24 [U-Boot] [PATCH 1/7] mtd: Fix function description in part_validate comment Otavio Salvador
2013-09-28 3:24 ` [U-Boot] [PATCH 2/7] doc: Fix a typo in the description in doc/README.JFFS2_NAND Otavio Salvador
2013-09-28 3:24 ` [U-Boot] [PATCH 3/7] include/linux/fb.h: Add a missing include for 'list.h' Otavio Salvador
2013-09-28 16:46 ` Fabio Estevam
2013-09-28 3:24 ` [U-Boot] [PATCH 4/7] gpio-led: Use __led_set in __led_init code Otavio Salvador
2013-09-28 3:24 ` [U-Boot] [PATCH 5/7] gpio-led: Fix __led_toggle support to first set GPIO as input Otavio Salvador
2013-09-28 13:12 ` Eric Bénard
2013-09-28 16:35 ` Fabio Estevam
2013-09-28 19:05 ` Otavio Salvador
2013-09-28 3:24 ` [U-Boot] [PATCH 6/7] status_led: Add support for inverted LEDs Otavio Salvador
2013-09-28 14:17 ` Benoît Thébaudeau
2013-09-28 16:49 ` Fabio Estevam
2013-09-28 19:08 ` Otavio Salvador
2013-09-29 13:40 ` Benoît Thébaudeau [this message]
2013-09-28 3:24 ` [U-Boot] [PATCH 7/7] cmd_led: Add support for inverted BIT leds Otavio Salvador
2013-09-28 13:06 ` [U-Boot] [PATCH 1/7] mtd: Fix function description in part_validate comment Eric Bénard
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=1799293256.2243041.1380462010404.JavaMail.zimbra@advansee.com \
--to=benoit.thebaudeau@advansee.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox