From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Cc: Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v4] leds: add SGI IP30 led support
Date: Sat, 22 Feb 2020 17:36:09 +0100 [thread overview]
Message-ID: <7bd606df-a5b6-6f05-43ef-b6691e16be94@gmail.com> (raw)
In-Reply-To: <20200222110545.fc96683543cb0dd538e5be82@suse.de>
On 2/22/20 11:05 AM, Thomas Bogendoerfer wrote:
> On Fri, 21 Feb 2020 21:31:04 +0100
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>
>>> + if (num == 0)
>>> + data->cdev.name = "white:indicator";
>>> + else
>>> + data->cdev.name = "red:indicator";
>>
>> Why indicator? Whereas it sounds quite generic it is used in the LED
>> subsystem specifically for naming indicator LEDs, that are often
>> found on flash LED controllers and are designed to indicate camera
>> sensor activity.
>
> ok, ic.
>
>> If it is on the front panel of SGI Octane workstations then its
>> function is perhaps well known?
>
> the red LED is clearly a fault led.
We have fault in common LED names, so you can go for it.
> The white LED will be switch on
> after system diagnostic was successfull. Nothing from common.h really
> fits that, maybe status ?
I think that "system" would be OK. There are some LED drivers
and DT bindings that use "system" in the LED names. I even proposed
that also in the initial versions of my patch set standardizing LED
naming but dropped it afterwards, since it its use was not clear.
But now we have good use case for it.
And one more thing: please add definitions for LEDs in your
driver like:
#define IP30_LED_SYSTEM 0
#define IP30_LED_FAULT 1
and use them instead of bare 0 and 1 numbers.
--
Best regards,
Jacek Anaszewski
prev parent reply other threads:[~2020-02-22 16:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 11:11 Thomas Bogendoerfer
2020-02-21 20:31 ` Jacek Anaszewski
2020-02-22 10:05 ` Thomas Bogendoerfer
2020-02-22 16:36 ` Jacek Anaszewski [this message]
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=7bd606df-a5b6-6f05-43ef-b6691e16be94@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=dmurphy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=tbogendoerfer@suse.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
all inboxes | Powered by JetHome®