From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1B8EC65BAF for ; Wed, 12 Dec 2018 09:59:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6D69320849 for ; Wed, 12 Dec 2018 09:59:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D69320849 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727026AbeLLJ7e (ORCPT ); Wed, 12 Dec 2018 04:59:34 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:44827 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726598AbeLLJ7d (ORCPT ); Wed, 12 Dec 2018 04:59:33 -0500 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 62335808B8; Wed, 12 Dec 2018 10:59:26 +0100 (CET) Date: Wed, 12 Dec 2018 10:59:29 +0100 From: Pavel Machek To: Rob Herring Cc: Jacek Anaszewski , Linux LED Subsystem , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , Baolin Wang , Daniel Mack , Dan Murphy , Linus Walleij , Oleh Kravchenko , Sakari Ailus , Simon Shields Subject: Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties Message-ID: <20181212095929.GA13437@amd> References: <1541542052-10081-1-git-send-email-jacek.anaszewski@gmail.com> <1541542052-10081-5-git-send-email-jacek.anaszewski@gmail.com> <5bea0eb8.1c69fb81.6b921.80e6@mx.google.com> <0a0b176c-4eb4-4b0e-6c3c-b3c6c8f5fff5@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: 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 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > We would also probably need different DT properties for different > > types of devices, since e.g. for network case the network interface > > name would fit better for the LED name, than the phy name, > > and we would need to know what type of device name we're going > > to look for. > > > > Pavel gave following examples: > > > > eth0:green:link > > adsl0:green:link > > adsl0:red:error > > > > So we would have e.g.: > > > > associated-vl42-device =3D <&camera1>; > > associated-network-device =3D <&phy1>; > > associated-block-device =3D <&phy1>; >=20 > Variable property names are kind of a pain to parse. >=20 > Perhaps when LEDs are associated with a device, we shouldn't care > within the context of the LED subsystem what the name is. The > association is more important and if you have that exposed, then you > don't really need to care what the name is. You still have to deal > with a device with more than 1 LED, but that becomes a problem local > to that device. >=20 > What I'm getting at is following a more standard binding pattern of > providers and consumers like we have for gpios, clocks, etc. So we'd > have something like this: >=20 > ethernet { > ... > leds =3D <&green_led>, <&red_led>; > led-names =3D "link", "err"; > }; >=20 > We can still support defining LED names as we've done, but we don't > have to come up with some elaborate naming convention that covers > every single case. I see that it would be more consistent with how gpios work, but I'm afraid this does not fit LEDs properly. With power LED, you want to be able to say "this is just on". Some poeple like heartbeat, and have LED for that. There may be LED for "disk activity", meaning activity on any harddrive. And there may be activity LED for specific disk. Only in the last case it would be suitable to have LED reference as a child of an device... Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlwQ3AEACgkQMOfwapXb+vLW1wCdFi1UWGwFwbU0j+ZGao50rC9A lZ0AoJakjBzMr4Cnacqy7Zw3QTF0pKES =LuwX -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--