From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
NXP Linux Team <linux-imx@nxp.com>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@collabora.com, Ian Ray <ian.ray@ge.com>,
Samu Nuutamo <samu.nuutamo@vincit.fi>
Subject: Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
Date: Fri, 29 May 2020 20:03:06 +0200 [thread overview]
Message-ID: <20200529180306.pjevb6qdv7jvmxtu@earth.universe> (raw)
In-Reply-To: <20200529160204.GA6025@duo.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]
Hi,
On Fri, May 29, 2020 at 06:02:04PM +0200, Pavel Machek wrote:
> > ping?
>
> Well, I thought that we maybe do not need standard LEDs on medical hardware.
The discussion died and the patch was not applied :) In general
IDK how worthwhile it is to use standard LED names for them. I
suppose the number of people planning to create something like
OpenWRT for medical devices is not so big.
> > On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > > From: Ian Ray <ian.ray@ge.com>
> > > > >
> > > > > Use kernel LED interface for the alarm LEDs.
> > > >
> > > > Could we get these changes cced to LED maintainers?
> > >
> > > Sorry, you are not turning up via get_maintainer.pl and usually
> > > subsystem maintainers are not CC'd for every DT device instance.
> > > E.g. I do not want to be always CC'd for DT board file containing
> > > a battery/charger. I'm quite surprised you want to be CC'd for
> > > them, just looking at ARM DT files there are over 1000 instances
> > > of leds.
>
> Well, we have mess in the naming; I'd like to clear it up.
I understand.
> > > > > + alarm1 {
> > > > > + label = "alarm:red";
> > > > > + gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > > + };
> > > >
> > > > So... What is function of these leds, and can we get naming more
> > > > consistent with rest of the kernel?
> > >
> > > The device is a medical patient monitor and these are alarm LEDs
> > > informing about critical device or patient status. They are
> > > referenced by their color (those are discrete LEDs, not a
> > > multi-color one) basically everywhere. The only exception is
> > > "silenced", which means that audible alarm is surpressed. I
> > > don't think we have something comparable for any of those LEDs
> > > in the mainline tree.
>
> Actually, we have "platform:*:mute" LEDs, that could be used for
> "silenced".
I see you point, but wonder if mute is the right choice. The LED
signals a silenced alarm, which IMHO is not the same:
* The alarm silencing is temporary and system unsilences after
1-2 minutes.
* LED is usually blinking instead of solid like a laptop mute LED
(so that operator is aware of silenced alarm)
* Device usually cannot be put into silenced mode before the alarm
appears
* Some medical devices still generate perodic beeps
AFAIK this is named alarm silencing by basically everyone for
medical devices. So I think naming this platfrom:*:mute would
increase the mess.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-05-29 18:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 14:51 [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface Sebastian Reichel
2020-04-24 9:32 ` Pavel Machek
2020-04-24 12:44 ` Sebastian Reichel
2020-05-29 14:05 ` Sebastian Reichel
2020-05-29 16:02 ` Pavel Machek
2020-05-29 18:03 ` Sebastian Reichel [this message]
2020-05-29 22:52 ` Pavel Machek
2020-06-26 16:35 ` Sebastian Reichel
2020-07-11 10:39 ` Shawn Guo
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=20200529180306.pjevb6qdv7jvmxtu@earth.universe \
--to=sebastian.reichel@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=festevam@gmail.com \
--cc=ian.ray@ge.com \
--cc=kernel@collabora.com \
--cc=kernel@pengutronix.de \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=samu.nuutamo@vincit.fi \
--cc=shawnguo@kernel.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