linux-kernel - Re: [PATCH v5 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211220085220.23753298@md1za8fc.ad001.siemens.net>
Date:   Mon, 20 Dec 2021 08:53:55 +0100
From:   Henning Schild <henning.schild@...mens.com>
To:     Pavel Machek <pavel@....cz>
CC:     Hans de Goede <hdegoede@...hat.com>,
        <linux-kernel@...r.kernel.org>, <linux-leds@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>,
        <linux-watchdog@...r.kernel.org>,
        Srikanth Krishnakar <skrishnakar@...il.com>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        "Gerd Haeussler" <gerd.haeussler.ext@...mens.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Mark Gross <mgross@...ux.intel.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Enrico Weigelt <lkml@...ux.net>
Subject: Re: [PATCH v5 2/4] leds: simatic-ipc-leds: add new driver for
 Siemens Industial PCs

Am Sun, 19 Dec 2021 17:49:03 +0100
schrieb Pavel Machek <pavel@....cz>:

> On Wed 2021-12-15 21:53:56, Hans de Goede wrote:
> > Hi,
> > 
> > On 12/15/21 21:18, Pavel Machek wrote:  
> > > On Mon 2021-12-13 13:05:00, Henning Schild wrote:  
> > >> This driver adds initial support for several devices from
> > >> Siemens. It is based on a platform driver introduced in an
> > >> earlier commit.
> > >>
> > >> One of the supported machines has GPIO connected LEDs, here we
> > >> poke GPIO memory directly because pinctrl does not come up.
> > >>
> > >> Signed-off-by: Henning Schild <henning.schild@...mens.com>  
> > > 
> > > Acked-by: Pavel Machek <pavel@....cz>  
> > 
> > I see that this patch #includes
> > linux/platform_data/x86/simatic-ipc-base.h which gets added by
> > patch 1/4.
> > 
> > Pavel, can I take this patch upstream through the pdx86 tree (with
> > you Ack added)? Or shall I prepare an immutable branch with patch 1
> > for you to merge ?  
> 
> Yes, you can.
> 
> 
> > >> +
> > >> +static struct simatic_ipc_led simatic_ipc_leds_io[] = {
> > >> +	{1 << 15, "green:" LED_FUNCTION_STATUS "-1" },
> > >> +	{1 << 7,  "yellow:" LED_FUNCTION_STATUS "-1" },
> > >> +	{1 << 14, "red:" LED_FUNCTION_STATUS "-2" },
> > >> +	{1 << 6,  "yellow:" LED_FUNCTION_STATUS "-2" },
> > >> +	{1 << 13, "red:" LED_FUNCTION_STATUS "-3" },
> > >> +	{1 << 5,  "yellow:" LED_FUNCTION_STATUS "-3" },
> > >> +	{ }
> > >> +};  
> 
> But I'd still like better naming than red:status-2.

We had the name discussion already several times, and i have to admit i
am not too happy either.

But my impression was that this is an acceptable compromise. I am not
happy because the names lack scope, which i had in the first round with
"simatic-ipc:red:...".

Function is also a bit unclear, but with the numbers and the user
manual, or looking at the chassis it kind of adds up and should be
clear to users which is which.

But i agree with Hans that we should sort this out before merge. So
please say what makes you unhappy, maybe that can be fixed ... might
even make me happier about the names i feel i had to choose.

The LEDs are per definition of the manuals meant for users/applications
to signal whatever the use-case might want to signal. There are 3 of
them numbered 1-3 on the chassis, and next to the number can often (not
always) be found a string like "error", "maint", "run-stop"
So a function suggestion i would say.

I could envision to use "fault" or "alarm" instead of "status" for the
one labeled "error". And maybe "standby" for the one called "maint" but
i would really like to keep the numbers.

Which would look like

status-1
alarm-2
standby-3

But still i have to clue what those names stand for and choosing
and of those "undefined" names could just suggest things and break
expectations. Calling them all "status" is neutral ... 

Or can you explain the difference between "fault", "panic" and "alarm".
Ask 5 people and get at least 3 different expectations ... i guess.

Henning

> 								Pavel