Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1212180imu; Fri, 9 Nov 2018 12:44:05 -0800 (PST) X-Google-Smtp-Source: AJdET5cd2FKrh/U4iH1ASIOErUiDM61Km5foWT162QO5Chem8nxNqP0iJVVhVkvBsp1Vc0+ILcBH X-Received: by 2002:aa7:87d0:: with SMTP id i16-v6mr10425892pfo.20.1541796245647; Fri, 09 Nov 2018 12:44:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541796245; cv=none; d=google.com; s=arc-20160816; b=MBbBnhEHbp28BVlkVenM2BTB9GT9Tdg4sIvfoO4t7EFBVPUFPDNK0LSRm7z31O1oEP 8Ud/Nzm35NIG/uQIVkB0dNpTYCTOXSJHN9vUir5T12XPlOKn0GYlScB2py4+rRLkuJkE jGfUWrbsmOhzO+k+M9IUo7rCyUYj1uYRSDx/p/+M6EEcpV1sN+EGMBxsbzE+OZ74+06b TXYOynVVbaClmPYAGHBjzovu2OdPtyWXp4b9n4aNI3e2w9Ik1CvqiMz45W9TlQl4g1Ni yLzVmP4xJlB20KzakPrpNE+gmNxg9HutPXq7GgOJ5dt+7AAXb8//G7KOchkUxJmD6t+z gPxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=EicsfJjbxmnOxlY5wu7LX8cpcT21JFm1l3YAUagB6vo=; b=BlfVeITL1Po5qP7nq8Rso9beMj1mbM/zcWIG86KS3UF6lGrOKXeRFIdn76VyIcdwdX 84JHmSMBErYPpJnA/CyP83UTCuKi0cj6+RuOtHb1DyOBNBsf4eGDaKK1zHxqFXvTC41I cAhF6ojC3Hhkk+XfqGs3QFhMsQ06pfbbogVLtywqhq9uW4x5DAQvODS7PzMEp17PQ3o2 0uH/WuDjoOhQwXEDXiIxs1RN8VMMrMhWNn9DDGCGS0orQeOQjxb2XBSDfKMY7fKuCQrQ YddM1+TnKWIjDO+HzDvAHrEqfreFlJA/S04gEqrDqW3SqXI5+Yf8sstWnDrNuLOrK5yE 2ibQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o5CZz7os; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 89-v6si9015155plc.383.2018.11.09.12.43.49; Fri, 09 Nov 2018 12:44:05 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=o5CZz7os; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728342AbeKJGY1 (ORCPT + 99 others); Sat, 10 Nov 2018 01:24:27 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:33253 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726110AbeKJGY1 (ORCPT ); Sat, 10 Nov 2018 01:24:27 -0500 Received: by mail-lf1-f68.google.com with SMTP id i26so2291886lfc.0; Fri, 09 Nov 2018 12:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EicsfJjbxmnOxlY5wu7LX8cpcT21JFm1l3YAUagB6vo=; b=o5CZz7osWirVig3z/u/H9SbqmGMsZ7xIGLYRnovUbC7Iu6NcFRNKWnNRbyBV/bggBg Yj+ghZPeGHhOLN7E+DDsPtLS1q0pWgg3UTQ34d5WoFMvcE058OPhiecHFXyBBmSJWOma BrkgF+lp8tuaUdomFVXVCE+kg6aNMV/GOefBQb5ZnzPA/RA1o+4AH2yww9OaglHOIICE SQm/m0WbrzGlqrf7ZrNsJMEqOK1b0nhLQziypOPFEgB8FYkST4KktYgtyQhBkBIbezGx g6hTaTat0svSf0IVqGeH7hZ+bLGc09w1AAI98LWpVwEY++0hNyjQZfo5MwkmAynDPLih z2Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EicsfJjbxmnOxlY5wu7LX8cpcT21JFm1l3YAUagB6vo=; b=bU8m6F3nEmTNjzLsPMB7ahrFnfp9egatinhELUQ3g/NTNKN/SLbdL3hlPWQ7i5wCIk l4TOlm5E0uBbxBpLJLk52QuvZ0d/mpjuv0Qvxzi2/fNyFTP75JtIJBbLeuWKYE9SoMGb AujOQRauDh9tSqRKCi+FjX7yETIxLytsjqOj1abJh8WkyqAyA6/78KkdviaYriRMiJDn +ml7Rhe7b+HN2eCRTZkZTv+gcJYhs6lfrTmJcsv+o2+IE6dnX+IjKzcrZVWL4785oJnr W6ngswuAuhhgB3JCjX3PsavVOrhkHH0BiqFTVczPJquD+TsfUStIyFufHgVBv+UJwVv4 4y+w== X-Gm-Message-State: AGRZ1gLS8FB1v/c2UGaBwonsaNBU4d7yRNGw4332742XlwkaT2jpBxhe 3hc4Zk8nMFnN8T3R0A5Ki9s= X-Received: by 2002:a19:aace:: with SMTP id t197mr6221436lfe.7.1541796130840; Fri, 09 Nov 2018 12:42:10 -0800 (PST) Received: from [192.168.1.18] (coo53.neoplus.adsl.tpnet.pl. [83.31.194.53]) by smtp.gmail.com with ESMTPSA id a9sm1574888lfa.19.2018.11.09.12.42.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Nov 2018 12:42:10 -0800 (PST) Subject: Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties To: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= , linux-leds@vger.kernel.org Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, pavel@ucw.cz, robh@kernel.org, Baolin Wang , Daniel Mack , Dan Murphy , Linus Walleij , Oleh Kravchenko , Sakari Ailus , Simon Shields , Xiaotong Lu References: <1541542052-10081-1-git-send-email-jacek.anaszewski@gmail.com> <1541542052-10081-5-git-send-email-jacek.anaszewski@gmail.com> From: Jacek Anaszewski Message-ID: Date: Fri, 9 Nov 2018 21:42:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vesa, On 11/09/2018 09:32 AM, Vesa Jääskeläinen wrote: > On 07/11/2018 0.07, Jacek Anaszewski wrote: >> Introduce dedicated properties for conveying information about >> LED function and color. Mark old "label" property as deprecated. >> >> Signed-off-by: Jacek Anaszewski >> Cc: Baolin Wang >> Cc: Daniel Mack >> Cc: Dan Murphy >> Cc: Linus Walleij >> Cc: Oleh Kravchenko >> Cc: Sakari Ailus >> Cc: Simon Shields >> Cc: Xiaotong Lu >> --- >>   Documentation/devicetree/bindings/leds/common.txt | 52 >> +++++++++++++++++++---- >>   1 file changed, 44 insertions(+), 8 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/leds/common.txt >> b/Documentation/devicetree/bindings/leds/common.txt >> index aa13998..3efc826 100644 >> --- a/Documentation/devicetree/bindings/leds/common.txt >> +++ b/Documentation/devicetree/bindings/leds/common.txt >> @@ -10,14 +10,20 @@ can influence the way of the LED device >> initialization, the LED components >>   have to be tightly coupled with the LED device binding. They are >> represented >>   by child nodes of the parent LED device binding. >>   + >>   Optional properties for child nodes: >>   - led-sources : List of device current outputs the LED is connected >> to. The >>           outputs are identified by the numbers that must be defined >>           in the LED device binding documentation. >> +- function: LED functon. Use one of the LED_FUNCTION_* prefixed >> definitions >> +        from the header include/dt-bindings/leds/functions.h. >> +        If there is no matching LED_FUNCTION available, add a new one. >> +- color : Color of the LED. > > We have had for years out-of-tree patch for multi color gpio led driver > which extends this concept with multiple colors. Then in sysfs there has > been possibility to control the color and otherwise use blinking or > other features. > > Our need is multi color status led of the device which includes > different kind of blinkings and colors on different situations. > > Current in-tree gpio led driver just wasn't atomic enough and a bit > clumsy interface for handling this. > > Now that this is being looked at could we come up with solution that we > could define multiple colors for one led in device tree and then we > could work on getting the driver upstreamed? > > What we did was generally: > > leds-multi { >     compatible = "gpio-multi-leds"; > >     status { >         gpios = <...>; >         linux,default-trigger = "none"; >         deafult-state = "keep"; > >         color-red { >             pin-mask = <0x01>; >         }; > >         color-green { >             pin-mask = <0x02>; >         }; > >         color-orange { >             pin-mask = <0x03>; >         }; >     }; > }; > Device Tree node implementation doesn't actually say too much about the sysfs interface you came up with, which is most vital in this case. Support for RGB LEDs, or other variations of LED synchronization have been approached several times, but without satisfying result so far. Generally the problem boils down to the issue of how triggers should handle multiple synchronized LED class devices in a backwards compatible way with monochrome LEDs. At some point the HSV [0] approach was proposed, but there was a problem with getting uniform colors across devices. Especially white. Certainly a calibration mechanism would be required. [0] https://lkml.org/lkml/2017/8/30/423 -- Best regards, Jacek Anaszewski