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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 30 May 2020 00:52:17 +0200
From:   Pavel Machek <pavel@....cz>
To:     Sebastian Reichel <sebastian.reichel@...labora.com>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...labora.com,
        Ian Ray <ian.ray@...com>, Samu Nuutamo <samu.nuutamo@...cit.fi>
Subject: Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface

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.

:-)

> > > > 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.

Ok, I guess it does not matter much. Generally no two LEDs behave
exactly the same, and I'd believe this would be close enough, but
... it really does not matter.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ