Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3910834imu; Mon, 12 Nov 2018 02:36:32 -0800 (PST) X-Google-Smtp-Source: AJdET5fQ27MybkX10QGTRV5C8nzissVyL31P/htIMdoakG3IZx3NARHu4hEaiPlLd5+F9rgwEq+X X-Received: by 2002:a63:fd53:: with SMTP id m19mr359822pgj.340.1542018991943; Mon, 12 Nov 2018 02:36:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542018991; cv=none; d=google.com; s=arc-20160816; b=Cu00uWNxLz7hQCDhfKFI3reYzMzpc+7fDu638mEcMPEbW2wV+Iwf5mvYcnZGIhVImG +dvD3UvdhmGscdgf+aVRTxSOdpWBYOMhKumdZtjJo6fzJQf+bmhuC9YnxKkkmKSaUJ+9 0E6CTOenaGpmh/eXWKDquVEoidRD/K/AHkwe7hRs7X2vmhuXDtG9K9c9gJ7EvQG37XhH I+tM7d6T4roQLFnyWFFF+8eTpXhHjM2J466U3j6JCAWaLXwXvY4I4I3LLF1LL6Pu+7ZV UJOCaTKD7VZva+s3Atdb/FS94FOQJgZ06Q1rib03K/Ti8hgRl5Pq7WUld4x1fWCfy5Oq dDaw== 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=ZxOR7WpHvYH2Irt+Chr1SK/LtroIPnVb2T4se6O+nTw=; b=jZoFojpTt9vZFdmMQeYylpw0zXtD2tmh1BtnAk9rCnqmztoPHsFQCTmeEpBwR6IswX 0MOOGGyqwD5ul2B1BejtjdisVicLCgZXJihlwhaLIXKzEUMWqX1IjPati583dJaor4fE 12Ti70/17VqZA5errzEq5PiqiKx3quIyxLPtyEyjy545zdOo4kGL/HoLoUof4uKjrwwf Du+7Hj9lnvNX3oUJ/yo75zZ8Gu4RmcVUT36WefV6aMpND37/vG2q8mQY05RTe2hVQaIT hnB/S/0r6271fN1Q0J+3NJN0ilOsjCpng5ve0hdnaV2/pQF/ugwu9vETc8II3cLO1m53 fV+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 19si15974780pgp.186.2018.11.12.02.36.17; Mon, 12 Nov 2018 02:36:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729348AbeKLU1z (ORCPT + 99 others); Mon, 12 Nov 2018 15:27:55 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:43088 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727204AbeKLU1z (ORCPT ); Mon, 12 Nov 2018 15:27:55 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 9C70880708; Mon, 12 Nov 2018 11:35:11 +0100 (CET) Date: Mon, 12 Nov 2018 11:35:13 +0100 From: Pavel Machek To: Jacek Anaszewski Cc: linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, robh@kernel.org, Baolin Wang , Daniel Mack , Dan Murphy , Linus Walleij , Oleh Kravchenko , Sakari Ailus , Simon Shields , Xiaotong Lu Subject: Re: [PATCH 02/24] leds: core: Add support for composing LED class device names Message-ID: <20181112103513.GB5695@amd> References: <1541542052-10081-1-git-send-email-jacek.anaszewski@gmail.com> <1541542052-10081-3-git-send-email-jacek.anaszewski@gmail.com> <20181111120234.GA28794@amd> <20181111201605.GA20160@amd> <57b77d4e-39a0-aaf2-5952-c2c25dc58593@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <57b77d4e-39a0-aaf2-5952-c2c25dc58593@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >> It's overcomplicating the naming again. In every case you can tweak > >> the function name to eth0_link, eth1_link etc. > >=20 > > Well, but in such case it would be good to keep existing scheme. > >=20 > > My system looks like this: > >=20 > > input16::capslock tpacpi::bay_active tpacpi::standby > > input16::numlock tpacpi::dock_active tpacpi::thinklight > > input16::scrolllock tpacpi::dock_batt tpacpi::thinkvantage > > input5::capslock tpacpi::dock_status1 tpacpi::unknown_led > > input5::numlock tpacpi::dock_status2 tpacpi::unknown_led2 > > input5::scrolllock tpacpi:green:batt tpacpi::unknown_led3 > >=20 > > I agree that we should get rid of "tpacpi:" part in some cases. But > > it does not make sense to get rid of "input16:" part -- it tells you > > if the LED is on USB or on built-in keyboard. > >=20 > > Ideally, tpacpi::thinklight would be input5::frontlight (as it is > > frontlight for the keyboard). > >=20 > > Yes we should simplify, but it still needs to work in all cases. >=20 > Well, label is not being removed. You still can use it an the old > fashion, even when using new led_compose_name(). >=20 > Maybe removing the description of the old LED naming from > Documentation/leds/leds-class.txt was too drastic move. > I'll keep it next to the new one, and only add a note that > it is kept only for backwards compatibility. I agree that removing it is "just too drastic". But it is not just for backwards compatibility. See my examples above, it is needed to tell which device the LED is asociated with, and it is absolutely required for USB devices (for example). And even for "embedded" stuff like routers, we want eth0:green:link, eth0:yellow:activity and not some kind of hack. Ideally, colors would come from fixed list, functions would come from fixed list, and device part would come from name used elsewhere in the kernel. (And yes, it probably means we should have something in device tree to link LED to its device. device =3D "name" would be good start...) Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlvpV2EACgkQMOfwapXb+vJHygCfZngO0ozX1gBL+B+xCkXI/KeM YvwAoJQTbDB5UxyDTDl2rTh8xZe+Unvn =WFvx -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD--