From: Hans de Goede <hdegoede@redhat.com>
To: Henning Schild <henning.schild@siemens.com>, Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
platform-driver-x86@vger.kernel.org,
linux-watchdog@vger.kernel.org,
Srikanth Krishnakar <skrishnakar@gmail.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Gerd Haeussler <gerd.haeussler.ext@siemens.com>,
Guenter Roeck <linux@roeck-us.net>,
Wim Van Sebroeck <wim@linux-watchdog.org>,
Mark Gross <mgross@linux.intel.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Enrico Weigelt <lkml@metux.net>
Subject: Re: [PATCH v5 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
Date: Thu, 23 Dec 2021 18:21:11 +0100 [thread overview]
Message-ID: <cb2915c5-831a-f2cf-55be-633ea21fa048@redhat.com> (raw)
In-Reply-To: <20211220091434.2f696d76@md1za8fc.ad001.siemens.net>
Hi,
On 12/20/21 09:14, Henning Schild wrote:
> Am Mon, 20 Dec 2021 08:53:55 +0100
> schrieb Henning Schild <henning.schild@siemens.com>:
>
>> Am Sun, 19 Dec 2021 17:49:03 +0100
>> schrieb Pavel Machek <pavel@ucw.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@siemens.com>
>>>>>
>>>>> Acked-by: Pavel Machek <pavel@ucw.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.
>
> Long story short, i am also not happy but the current suggestion is the
> most generic and least "expectation-creating" i could come up with.
> While keeping a mapping between the name and the chassis/manual.
>
> So i will stick with it, unless i get concrete suggestions on how to
> improve.
Ok, given the above I've gone ahead and merged this series.
I too believe the current status names are fine, but if someone disagrees,
they still have the entire 5.17 cycle to come up with something better.
Regards,
Hans
next prev parent reply other threads:[~2021-12-23 17:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 12:04 [PATCH v5 0/4] add device drivers for Siemens Industrial PCs Henning Schild
2021-12-13 12:04 ` [PATCH v5 1/4] platform/x86: simatic-ipc: add main driver for Siemens devices Henning Schild
2021-12-13 12:05 ` [PATCH v5 2/4] leds: simatic-ipc-leds: add new driver for Siemens Industial PCs Henning Schild
2021-12-15 20:18 ` Pavel Machek
2021-12-15 20:53 ` Hans de Goede
2021-12-19 16:49 ` Pavel Machek
2021-12-19 19:12 ` Hans de Goede
2021-12-20 7:53 ` Henning Schild
2021-12-20 8:14 ` Henning Schild
2021-12-23 17:21 ` Hans de Goede [this message]
2022-05-13 19:40 ` Henning Schild
2022-05-13 21:47 ` Guenter Roeck
2021-12-13 12:05 ` [PATCH v5 3/4] watchdog: simatic-ipc-wdt: add new driver for Siemens Industrial PCs Henning Schild
2021-12-15 20:56 ` Hans de Goede
2021-12-15 21:52 ` Guenter Roeck
2021-12-13 12:05 ` [PATCH v5 4/4] platform/x86: pmc_atom: improve critclk_systems matching for Siemens PCs Henning Schild
2021-12-13 12:21 ` [PATCH v5 0/4] add device drivers for Siemens Industrial PCs Henning Schild
2021-12-13 14:37 ` Andy Shevchenko
2021-12-23 17:17 ` Hans de Goede
2022-01-03 12:53 ` Henning Schild
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=cb2915c5-831a-f2cf-55be-633ea21fa048@redhat.com \
--to=hdegoede@redhat.com \
--cc=andy.shevchenko@gmail.com \
--cc=gerd.haeussler.ext@siemens.com \
--cc=henning.schild@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lkml@metux.net \
--cc=mgross@linux.intel.com \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=skrishnakar@gmail.com \
--cc=wim@linux-watchdog.org \
/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