Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1225726ybm; Sat, 30 May 2020 02:31:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx4KEQhpZRGEDxfn0EunFCBbTkuLQFkRTnTxnPLJOaj7iD8DfuBh+YET7KkGLvTRbWw4iWK X-Received: by 2002:a17:906:34c4:: with SMTP id h4mr12129326ejb.167.1590831076012; Sat, 30 May 2020 02:31:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590831076; cv=none; d=google.com; s=arc-20160816; b=bSON6mGVK4jUnCJ6HVoOUBxpR3LQ9MPuwOoys8VrlX8sLIRAD+b8J41DKHsdCIt4X5 6XHSfh3KuCuOm1ipMtqwry/vK0mD/czcwyx1oLnfenuI8RX/eoAIlVz4S+JZpQ7I3P1u InsuqlLCpc+VPXHPMFPbFFrJkRXTpHlnPz7m2H3hbgBtR4IF/U/9gZSzFkCT5ph/PSGC SgeOkRAG1nThiTd2JWSZBMazPw/Xmd9lz18z529Tf9M/DjeD1MhKmQFT6nSu7/EbqCXs YUQcCGQf7YpDt/GXUTT2j8ic5dfQ5Aw2TsEVdEIBbYmDN13SAUdgPxVdAZddkJ3wU9ab aWZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=VL42xGzs0rNlENinMRdcATw5Kl9jJ5s4KcHYWwJjpEY=; b=XwnM+40afDn913okOan4LPpi7dZl0ra6OUQ34nN2sAh4llAGWXL9FFkscHExnM5iRS tHWTGyt7+y05mRoVr5FewgeBNiJKnm1Y1fvCD/HRt196Q8G2DlyOWNfiDxuijzH0snEP QQi4E04WaxgH0Pw4nIxbP+xr4dFrYlg+FtUrSIfieSL3xNJ9CSSzvwnzlJFb0waf8Y+A +Xrr8C/gmTMipTwGtEi8eECy+FkorRYGRBU5ShKXQPLUiYDSSxa/s3Lq/MAZ5vg55wyT 1498otmTqdUfn/eXfXoWQJKjVMWmWnjcvHe8/+8JZkaNA8kNZ2g+JFpoDJyPOOvkBs1t u+fA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l64si6491076ede.102.2020.05.30.02.30.53; Sat, 30 May 2020 02:31:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728511AbgE3J1B (ORCPT + 99 others); Sat, 30 May 2020 05:27:01 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:56670 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727964AbgE3J1A (ORCPT ); Sat, 30 May 2020 05:27:00 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 69F3B1C0C0E; Sat, 30 May 2020 00:52:17 +0200 (CEST) Date: Sat, 30 May 2020 00:52:17 +0200 From: Pavel Machek To: Sebastian Reichel Cc: Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rob Herring , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@collabora.com, Ian Ray , Samu Nuutamo Subject: Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface Message-ID: <20200529225217.GA23601@duo.ucw.cz> References: <20200416145123.73039-1-sebastian.reichel@collabora.com> <20200424093226.GB2647@amd> <20200424124423.jo25ai5oifvalgpr@earth.universe> <20200529140555.ozlvz4egihkvo3aw@earth.universe> <20200529160204.GA6025@duo.ucw.cz> <20200529180306.pjevb6qdv7jvmxtu@earth.universe> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <20200529180306.pjevb6qdv7jvmxtu@earth.universe> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > On Fri, May 29, 2020 at 06:02:04PM +0200, Pavel Machek wrote: > > > ping? > >=20 > > Well, I thought that we maybe do not need standard LEDs on medical hard= ware. >=20 > 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. > >=20 > > Actually, we have "platform:*:mute" LEDs, that could be used for > > "silenced". >=20 > I see you point, but wonder if mute is the right choice. The LED > signals a silenced alarm, which IMHO is not the same: >=20 > * 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 >=20 > 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 =2E.. it really does not matter. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXtGSIQAKCRAw5/Bqldv6 8t7PAJ9ow6Q+gMjdqrdDFtfPSloIuwM0NgCfVMVP20+FwwaIKnq0iwnn6/DdIDM= =BaAq -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM--