[{"id":1561481,"web_url":"http://patchwork.ozlabs.org/comment/1561481/","msgid":"<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>","list_archive_url":null,"date":"2017-01-20T22:35:20","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"Hi Rafał,\n\nOn 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n> From: Rafał Miłecki \n> \n> Some LEDs can be related to particular devices described in DT. This\n> property allows specifying such relations. E.g. USB LED should usually\n> be used to indicate some USB port(s) state.\n> \n> Signed-off-by: Rafał Miłecki \n> ---\n> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n> allows specifying other devices as well.\n> \n> When bindings patch is related to some followup implementation, they usually go\n> through the same tree.\n> \n> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n> way to solve this dependency issue? Or should this patch wait until 3.11 is\n> released?\n> ---\n> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n> 1 file changed, 16 insertions(+)\n> \n> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n> index 24b656014089..17632a041196 100644\n> --- a/Documentation/devicetree/bindings/leds/common.txt\n> +++ b/Documentation/devicetree/bindings/leds/common.txt\n> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n> - panic-indicator : This property specifies that the LED should be used,\n> \t\t if at all possible, as a panic indicator.\n> \n> +- led-triggers : List of devices that should trigger this LED activity. Some\n> +\t\t LEDs can be related to a specific device and should somehow\n> +\t\t indicate its state. E.g. USB 2.0 LED may react to device(s) in\n> +\t\t a USB 2.0 port(s). Another common example is switch or router\n> +\t\t with multiple Ethernet ports each of them having its own LED\n> +\t\t assigned (assuminled-trigger-usbportg they are not hardwired).\n> +\t\t In such cases this property should contain phandle(s) of\n> +\t\t related device(s). In many cases LED can be related to more\n> +\t\t than one device (e.g. one USB LED vs. multiple USB ports) so a\n> +\t\t list of entries can be specified.\n> +\n\nThis implies that it is possible to define multiple triggers for\na LED class device but it is not supported by LED Trigger core.\nThere is linux,default-trigger property which allows to define one\ntrigger that will be initially assigned.\n\nI am aware that this is renamed usb-ports property from v1,\nthat attempts to address Rob's comment, but we can't do that this way.\nMaybe usb-ports property could be documented in led-trigger-usbport's\nspecific bindings and a reference to it could be added next to the\nrelated entry on the list of the available LED triggers (which is\nactually missing) in Documentation/devicetree/bindings/leds/common.txt.\n\n> Required properties for flash LED child nodes:\n> - flash-max-microamp : Maximum flash LED supply current in microamperes.\n> - flash-max-timeout-us : Maximum timeout in microseconds after which the flash\n> @@ -69,6 +80,11 @@ gpio-leds {\n> \t\tlinux,default-trigger = \"heartbeat\";\n> \t\tgpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;\n> \t};\n> +\n> +\tusb {\n> +\t\tgpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;\n> +\t\tled-triggers = <&ohci_port1>, <&ehci_port1>;\n> +\t};\n> };\n> \n> max77693-led {\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v4wYq0Rfdz9t1Q\n\tfor ;\n\tSat, 21 Jan 2017 09:37:03 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751983AbdATWhB (ORCPT\n\t);\n\tFri, 20 Jan 2017 17:37:01 -0500","from mail-wm0-f68.google.com ([74.125.82.68]:35183 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751774AbdATWhA (ORCPT\n\t); Fri, 20 Jan 2017 17:37:00 -0500","by mail-wm0-f68.google.com with SMTP id d140so10058023wmd.2;\n\tFri, 20 Jan 2017 14:36:06 -0800 (PST)","from [192.168.1.17] (bgq93.neoplus.adsl.tpnet.pl. [83.28.80.93])\n\tby smtp.gmail.com with ESMTPSA id\n\te6sm1688690wrc.30.2017.01.20.14.36.02\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 20 Jan 2017 14:36:03 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"R5X+Uhky\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=kP/l/QMEm8hmlDW0Ow+759SMWDBaaD7Et5fFyFEQWfk=;\n\tb=R5X+Uhky3DI1/PHxOvHavgdH9DQALlP9Me7RSwxE6VNL9VF/iOJ/NrAf8DyLe/nIxA\n\tSf2Zf/z9wtCyhqwYMsT9Izy2OGhUCB3BEI4s3bVyc+xP6mKVGzmNgW7isyghACZ4W71F\n\tTkz5BiWv7rQad3sgaSn6kuKOvW6afNFk+2Fpy95LPuC6DutxBMNc4ufByWGrztqfn/Zu\n\toKeY6r1r6plfnINcKz0/PAhES6eleJUlIb6fdS4Fix7wLpEP6KKJULncpe5ay+DS3QDl\n\tDhLPTuNQt/b2Gr4dmwYQDDR5QSw5WK/AoYqewya2PhYEzcg4fsr8h8X4KIWeDy5JnXrh\n\teQkQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=kP/l/QMEm8hmlDW0Ow+759SMWDBaaD7Et5fFyFEQWfk=;\n\tb=gye7+XbJG6QlY6GWMJvkYSmo6lPCZbEhnPIXjYsgpKfGMiohW4QsCXfwmPtrlApb02\n\tuc9/AQBNh3LW3jutD5diEKWyYd9P1k2+4rVLt2e4b+CvozD6IsEG1YGBFZlYhSc8orrl\n\t+2HqoaBIrVQHD2nShui45a2BCW/viwTWjNUVg1p0Z+noMhaU0XXpDfQ4FHHMI5pxzClN\n\t0Q6qPebt/KXcJ096zffYV1/7opLa/hoHtjkS2/iVI7oBn8vrYdEdvS4rtkXEWXh9iqoR\n\tS1EaRUHkBI+vDRoVh5EA0j1CZdO8Lk12sNh8p3hWyLP6/upl4fMHIxHYoeZjcGCeUSlr\n\tUCSQ==","X-Gm-Message-State":"AIkVDXKBsqeO5vY8CKpmuuvQPcLOhSitRb++Kbni0qr4kydZSLIkw5fqT+9L6v1Evivl4A==","X-Received":"by 10.28.191.208 with SMTP id o77mr4866767wmi.117.1484951763993; \n\tFri, 20 Jan 2017 14:36:03 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tGreg Kroah-Hartman ","References":"<20170120215605.15728-1-zajec5@gmail.com>","Cc":"linux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tRob Herring , Mark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>","Date":"Fri, 20 Jan 2017 23:35:20 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"<20170120215605.15728-1-zajec5@gmail.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1561743,"web_url":"http://patchwork.ozlabs.org/comment/1561743/","msgid":"","list_archive_url":null,"date":"2017-01-21T16:24:38","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 20 January 2017 at 23:35, Jacek Anaszewski\n wrote:\n> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>> From: Rafał Miłecki \n>>\n>> Some LEDs can be related to particular devices described in DT. This\n>> property allows specifying such relations. E.g. USB LED should usually\n>> be used to indicate some USB port(s) state.\n>>\n>> Signed-off-by: Rafał Miłecki \n>> ---\n>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>> allows specifying other devices as well.\n>>\n>> When bindings patch is related to some followup implementation, they usually go\n>> through the same tree.\n>>\n>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>> released?\n>> ---\n>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>> 1 file changed, 16 insertions(+)\n>>\n>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>> index 24b656014089..17632a041196 100644\n>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>> - panic-indicator : This property specifies that the LED should be used,\n>> if at all possible, as a panic indicator.\n>>\n>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>> + LEDs can be related to a specific device and should somehow\n>> + indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>> + a USB 2.0 port(s). Another common example is switch or router\n>> + with multiple Ethernet ports each of them having its own LED\n>> + assigned (assuminled-trigger-usbportg they are not hardwired).\n>> + In such cases this property should contain phandle(s) of\n>> + related device(s). In many cases LED can be related to more\n>> + than one device (e.g. one USB LED vs. multiple USB ports) so a\n>> + list of entries can be specified.\n>> +\n>\n> This implies that it is possible to define multiple triggers for\n> a LED class device but it is not supported by LED Trigger core.\n> There is linux,default-trigger property which allows to define one\n> trigger that will be initially assigned.\n\nI think we owe some extra explanation to people not closely familiar\nwith the triggers.\n\nLinux has multiple trigger drivers each supporting some *type* of\nevents. Linux supports assigning only one trigger driver to LED at a\ntime.\nThis means you can use e.g.:\n1) \"usbport\" trigger driver that supports USB events\nXOR\n2) \"timer\" trigger driver that uses timer to control LED\nXOR\n3) \"cpu\" trigger driver that supports CPU events\nat once.\n\nWith proposed \"led-triggers\" property one could assign different\ntrigger *sources* to a LED. You could e.g. assign 2 USB ports, network\ndevice & CPU to a single LED. For reason explained above Linux\ncouldn't support all of them at once.\n\n\n> I am aware that this is renamed usb-ports property from v1,\n> that attempts to address Rob's comment, but we can't do that this way.\n> Maybe usb-ports property could be documented in led-trigger-usbport's\n> specific bindings and a reference to it could be added next to the\n> related entry on the list of the available LED triggers (which is\n> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n\nI'm wondering if we need to care about this Linux limitation and if it\nshould stop us from adding this flexible DT property. Maybe we could\nlive with Linux having limitation of supporting one trigger type at a\ntime? So e.g. if one assigns 2 USB ports + network device + CPU and\ndecides to use \"usport\" trigger driver he'll get LED indicating status\nof USB ports only.\n\nI think we could live with such limitation in Linux support for this\ngeneric \"led-triggers\" property. I think it's also not very common to\nhave LED with different types of devices assigned. Personally I've\nnever seen devices with LED label \"USB & CPU\" or whatever.\n\nWhat do you think about this? Maybe we could also document this\nlimitation in trigger docs.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v5NFm1GlLz9syB\n\tfor ;\n\tSun, 22 Jan 2017 03:24:44 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750826AbdAUQYk (ORCPT\n\t);\n\tSat, 21 Jan 2017 11:24:40 -0500","from mail-ot0-f196.google.com ([74.125.82.196]:36458 \"EHLO\n\tmail-ot0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750800AbdAUQYk (ORCPT\n\t); Sat, 21 Jan 2017 11:24:40 -0500","by mail-ot0-f196.google.com with SMTP id 36so10681836otx.3;\n\tSat, 21 Jan 2017 08:24:39 -0800 (PST)","by 10.202.237.3 with HTTP; Sat, 21 Jan 2017 08:24:38 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"iLOf8fRE\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=XZUoLH38mjZKgqyT5ldu0aqFZ3G7j06czFaNGZ1l8qE=;\n\tb=iLOf8fREgvQXjQh16ctTYQ1l9mkJT/cJwJ6QAKjVLWWZUexqzu+grzgvU8GtpFb2ZU\n\tOjGB/r3N7FIEUdAFTY2RF3IQmjSt8s/FJMTwxe8EzLMwa1fO8DDA4bQ0EUuU3Fh780Xh\n\tZY6dzNzkUdnnXYaSPjSmAOO4UZGpzSJ0+IxwPBfuiNcEYd5xA7IzslQx9IHkICy1Mn7g\n\tnVOVOSHqqtLOkhOlOBaQJSBfjwh8navQBdFMlqEv/y6ct2D9yvwUQ3K+YkIu4VNJcqkM\n\tUp9xziaVts2S2vrnEzTNpqps8zxxhnTL8nMothEnXbIBRQWYlagzE8YtscpwdW1qHG8J\n\tDv9w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=XZUoLH38mjZKgqyT5ldu0aqFZ3G7j06czFaNGZ1l8qE=;\n\tb=cLocy5QLM1qrXC4wGJT46ZENF7vYXHTlIaETfaqpm1IhOQcpFP741LO1YrGwjIYoFh\n\tKkDj+7eZIobJQVoD7lQV/Y3lieMGGIvOM9h90/erVuaOawkFzrn23/Ns+NbZpDCpb5wC\n\tKYGmcvBXvYgQuvLGziNOmUquLzSdXyxTMOAU7OiD7OkUfBVHcNYwTggjSxd7FOD5hV0K\n\toD0H8ek/+t+VZWjRbTnmKzprwG1fOmZjpL1XV8ZyYk0bm7E5Cha5udgvEI1BYeIelEQP\n\t0VNNn6XPuD3dgqMO8ss5hky017Sd2YgtzODR8x1vvsDjDTVNxgkzxedvCu+U5LnHQJBe\n\tgXug==","X-Gm-Message-State":"AIkVDXLlKZlpSef+/ync8ADfhz7v1ZT8qXyJmHyQDNztv+N3wLAeRml3io+YVreG2sgMSR52oLHgPs9rZ8LARw==","X-Received":"by 10.157.46.226 with SMTP id w89mr10541490ota.225.1485015879046;\n\tSat, 21 Jan 2017 08:24:39 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Date":"Sat, 21 Jan 2017 17:24:38 +0100","Message-ID":"","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"quoted-printable","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1561835,"web_url":"http://patchwork.ozlabs.org/comment/1561835/","msgid":"<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>","list_archive_url":null,"date":"2017-01-21T21:42:44","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n> On 20 January 2017 at 23:35, Jacek Anaszewski\n> wrote:\n>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>> From: Rafał Miłecki \n>>>\n>>> Some LEDs can be related to particular devices described in DT. This\n>>> property allows specifying such relations. E.g. USB LED should usually\n>>> be used to indicate some USB port(s) state.\n>>>\n>>> Signed-off-by: Rafał Miłecki \n>>> ---\n>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>> allows specifying other devices as well.\n>>>\n>>> When bindings patch is related to some followup implementation, they usually go\n>>> through the same tree.\n>>>\n>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>> released?\n>>> ---\n>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>> 1 file changed, 16 insertions(+)\n>>>\n>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>> index 24b656014089..17632a041196 100644\n>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>> - panic-indicator : This property specifies that the LED should be used,\n>>> if at all possible, as a panic indicator.\n>>>\n>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>> + LEDs can be related to a specific device and should somehow\n>>> + indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>> + a USB 2.0 port(s). Another common example is switch or router\n>>> + with multiple Ethernet ports each of them having its own LED\n>>> + assigned (assuminled-trigger-usbportg they are not hardwired).\n>>> + In such cases this property should contain phandle(s) of\n>>> + related device(s). In many cases LED can be related to more\n>>> + than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>> + list of entries can be specified.\n>>> +\n>>\n>> This implies that it is possible to define multiple triggers for\n>> a LED class device but it is not supported by LED Trigger core.\n>> There is linux,default-trigger property which allows to define one\n>> trigger that will be initially assigned.\n> \n> I think we owe some extra explanation to people not closely familiar\n> with the triggers.\n> \n> Linux has multiple trigger drivers each supporting some *type* of\n> events. Linux supports assigning only one trigger driver to LED at a\n> time.\n> This means you can use e.g.:\n> 1) \"usbport\" trigger driver that supports USB events\n> XOR\n> 2) \"timer\" trigger driver that uses timer to control LED\n> XOR\n> 3) \"cpu\" trigger driver that supports CPU events\n> at once.\n\nCorrect.\n\n> With proposed \"led-triggers\" property one could assign different\n> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n> device & CPU to a single LED. For reason explained above Linux\n> couldn't support all of them at once.\n> \n> \n>> I am aware that this is renamed usb-ports property from v1,\n>> that attempts to address Rob's comment, but we can't do that this way.\n>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>> specific bindings and a reference to it could be added next to the\n>> related entry on the list of the available LED triggers (which is\n>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n> \n> I'm wondering if we need to care about this Linux limitation and if it\n> should stop us from adding this flexible DT property. Maybe we could\n> live with Linux having limitation of supporting one trigger type at a\n> time?\n\nThat's what I meant. Generally I have objections to the generic\nproperty for defining list of allowed triggers. That's why I proposed\nto stay by usb-ports property that would be specific to only one\ntrigger: led-trigger-usbport.\n\nled-trigger-usbport in fact is an entirely new type of LED trigger.\nLED triggers is a kernel based source of events. All existing triggers\nreact only to a single, well defined source of events, whereas\nled-trigger-usbport allows to define the scope of events (usb ports)\nto notify about. Activity on each port is treated similarly and the LED\nclass device that listens to the trigger notifications doesn't know\nwhich exact port triggered the notification.\n\n>From this POV led-trigger-usbport is kind of facade, which allows\nfor it to fit well into the LED Trigger design and API, and usb ports\nare not identical with LED triggers, but sit rather one level below.\nIt is led-trigger-usbport which is visible to the LED subsystem, and\nnot every single usb port.\n\nTherefore it isn't logically justified to rename usb-ports property\nto led-triggers. The property should be specific to this trigger.\n\n> So e.g. if one assigns 2 USB ports + network device + CPU and\n> decides to use \"usport\" trigger driver he'll get LED indicating status\n> of USB ports only.\n\nHow would it be different from the current state? Only in limiting\nthe scope of triggers available for a LED class device.\n\n> I think we could live with such limitation in Linux support for this\n> generic \"led-triggers\" property. I think it's also not very common to\n> have LED with different types of devices assigned. Personally I've\n> never seen devices with LED label \"USB & CPU\" or whatever.\n\nI agree. Nonetheless led-triggers seems to support such a design.\n\n> What do you think about this? Maybe we could also document this\n> limitation in trigger docs.\n\nI'm not entirely sure if I got your point. Your reasoning seems\nself contradicting to me in few places.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v5WKh3xxTz9t0k\n\tfor ;\n\tSun, 22 Jan 2017 08:43:35 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751131AbdAUVnb (ORCPT\n\t);\n\tSat, 21 Jan 2017 16:43:31 -0500","from mail-wm0-f68.google.com ([74.125.82.68]:35539 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751025AbdAUVnb (ORCPT\n\t); Sat, 21 Jan 2017 16:43:31 -0500","by mail-wm0-f68.google.com with SMTP id d140so16001711wmd.2;\n\tSat, 21 Jan 2017 13:43:30 -0800 (PST)","from [192.168.1.17] (bgw112.neoplus.adsl.tpnet.pl. [83.28.86.112])\n\tby smtp.gmail.com with ESMTPSA id\n\tc9sm12668477wmi.16.2017.01.21.13.43.26\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSat, 21 Jan 2017 13:43:27 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"u6G0Ma3h\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=/k/WooUkTTEIZUuF3umnsr1GDwryhdSpPKbPncWW7zY=;\n\tb=u6G0Ma3hL10LbuUaCww/hWvC12Uq7WCXaKy6tjXBDdzCecGP/F+WowgdYHpB4zfvoz\n\tfUywGYJxvLC/faARVA7RvJOtuMick6QP8ThY7B86XuWVrZb0tNsU+n7OqYtP6bCtEPXJ\n\tcuM1yuU2Nl6Rr9ivJr08s7Otd28IT6gl9ykk5iWI6t1GthsViCY83agwPipEAgNfL9mC\n\tpSy4weS3ma2WVI+dXiIGCVrI7cdMx1NXFIHZlLXpgp6iqYOTMXdLMzK3p6lDvFztTD1P\n\tBdDVXyspeydY3uLFgJ++l/LqdtQ9Z7HSafz0kYt2V+dF3MPBHBeg1bZtXTKfiRKquyZB\n\tOs5A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=/k/WooUkTTEIZUuF3umnsr1GDwryhdSpPKbPncWW7zY=;\n\tb=qA/JI2q9x32ZC1LaX7PaoXPR6q/aFgY7WYYFAkYAiEQp17mI+NwWLY6Laxr718cDLY\n\tU5iF9D9vydMsZq5RwwDfCXaFZ6zdBqhYQGXsfO1AaWnv2HQJhYLwZ33bT7qn7rYXAvDO\n\tQUIPzJeK6Rbd55EUQE3ZYt00P6OdyIlTjzzjhniX2SsDUVSQToVSgcTPFLSvfAMiFAMu\n\tzqzd9dF04O586QGcU+WQ2x7QUgi07VnDV8RCJfNALmbaa3DnhMaLK0sFkxqfn4s8d3H3\n\tvjAFZ0dH+tz3U9gLZBbZI4kl3tterlDXoslNkGbo05XxsU+I96LvYSEDzFeYkbokZUAW\n\t2UNg==","X-Gm-Message-State":"AIkVDXJECf5j1LipBeKo+gACrejLv+KWbfUKufqavy6KPE4pzDycFKkrLpzNECnMEvIZYA==","X-Received":"by 10.28.211.200 with SMTP id k191mr7654566wmg.137.1485035008879;\n\tSat, 21 Jan 2017 13:43:28 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>","Date":"Sat, 21 Jan 2017 22:42:44 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1563003,"web_url":"http://patchwork.ozlabs.org/comment/1563003/","msgid":"<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>","list_archive_url":null,"date":"2017-01-23T16:45:37","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:\n> Hi Rafał,\n> \n> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n> > From: Rafał Miłecki \n> > \n> > Some LEDs can be related to particular devices described in DT. This\n> > property allows specifying such relations. E.g. USB LED should usually\n> > be used to indicate some USB port(s) state.\n> > \n> > Signed-off-by: Rafał Miłecki \n> > ---\n> > V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n> > allows specifying other devices as well.\n> > \n> > When bindings patch is related to some followup implementation, they usually go\n> > through the same tree.\n> > \n> > Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n> > adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n> > way to solve this dependency issue? Or should this patch wait until 3.11 is\n> > released?\n> > ---\n> > Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n> > 1 file changed, 16 insertions(+)\n> > \n> > diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n> > index 24b656014089..17632a041196 100644\n> > --- a/Documentation/devicetree/bindings/leds/common.txt\n> > +++ b/Documentation/devicetree/bindings/leds/common.txt\n> > @@ -49,6 +49,17 @@ Optional properties for child nodes:\n> > - panic-indicator : This property specifies that the LED should be used,\n> > \t\t if at all possible, as a panic indicator.\n> > \n> > +- led-triggers : List of devices that should trigger this LED activity. Some\n> > +\t\t LEDs can be related to a specific device and should somehow\n> > +\t\t indicate its state. E.g. USB 2.0 LED may react to device(s) in\n> > +\t\t a USB 2.0 port(s). Another common example is switch or router\n> > +\t\t with multiple Ethernet ports each of them having its own LED\n> > +\t\t assigned (assuminled-trigger-usbportg they are not hardwired).\n> > +\t\t In such cases this property should contain phandle(s) of\n> > +\t\t related device(s). In many cases LED can be related to more\n> > +\t\t than one device (e.g. one USB LED vs. multiple USB ports) so a\n> > +\t\t list of entries can be specified.\n> > +\n> \n> This implies that it is possible to define multiple triggers for\n> a LED class device but it is not supported by LED Trigger core.\n\nNot really relevant for designing (and future proofing) a binding.\n\n> There is linux,default-trigger property which allows to define one\n> trigger that will be initially assigned.\n> \n> I am aware that this is renamed usb-ports property from v1,\n> that attempts to address Rob's comment, but we can't do that this way.\n> Maybe usb-ports property could be documented in led-trigger-usbport's\n> specific bindings and a reference to it could be added next to the\n> related entry on the list of the available LED triggers (which is\n> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n\nI'm not going to accept something specific to USB. So the choice is make \nthe existing property work for USB or design something more flexible and \ngeneric.\n\nRob\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v6cg55Qv5z9sdm\n\tfor ;\n\tTue, 24 Jan 2017 03:47:29 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750732AbdAWQpw (ORCPT\n\t);\n\tMon, 23 Jan 2017 11:45:52 -0500","from mail-oi0-f66.google.com ([209.85.218.66]:33678 \"EHLO\n\tmail-oi0-f66.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750784AbdAWQpv (ORCPT\n\t); Mon, 23 Jan 2017 11:45:51 -0500","by mail-oi0-f66.google.com with SMTP id j15so11177815oih.0;\n\tMon, 23 Jan 2017 08:45:39 -0800 (PST)","from localhost (72-48-98-129.dyn.grandenetworks.net.\n\t[72.48.98.129]) by smtp.gmail.com with ESMTPSA id\n\tq130sm8824344oif.25.2017.01.23.08.45.38\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tMon, 23 Jan 2017 08:45:38 -0800 (PST)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent;\n\tbh=L2Tdq6Aom9PGTTQPEsxgOErmGQE9h6GVU3AOCPky+1g=;\n\tb=atpWAXAtlXdHjacaQR41CJ1+rAdkL+a47bFPKfE+empdhv4ww21MQWjlb8JS5Vowsj\n\tSIMa+QrWZtl7GxVdpMRVguTRZqHt/wX7tp5hXYhI+DdNwASnwDw3Vk+77fhye1TBdnxo\n\t35mfnrNSLyphjkOhPZuTA7IwiwV5q8PIm5fhSy9/TKf0qsCVk2na1uuMGb6wpuixRT4w\n\t8uUqCrazGDytu+jWhXPrf6t3rAtQ2z7kPlaPPqTLc9sxEPWJGlVlPvwR17SBuM/kGM7w\n\tG4oo2/ePnCYA7VxlU26sAkPuxjR6ywf9Z8u7bfkFWZUXMVvDp8AOvU4ZCL5InVBOOIs7\n\tT7Pg==","X-Gm-Message-State":"AIkVDXLH0B2kIbj7gdeVQDOK6D8VOVvj2SmXMlmb32R6B32JrUlQvheqEWUwG0hPlcdYAA==","X-Received":"by 10.202.196.87 with SMTP id u84mr15719480oif.44.1485189938878; \n\tMon, 23 Jan 2017 08:45:38 -0800 (PST)","Date":"Mon, 23 Jan 2017 10:45:37 -0600","From":"Rob Herring ","To":"Jacek Anaszewski ","Cc":"=?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tGreg Kroah-Hartman ,\n\tlinux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tMark Rutland ,\n\t=?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","Message-ID":"<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>","User-Agent":"Mutt/1.6.2-neo (2016-08-21)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1563278,"web_url":"http://patchwork.ozlabs.org/comment/1563278/","msgid":"","list_archive_url":null,"date":"2017-01-23T20:51:49","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 01/23/2017 05:45 PM, Rob Herring wrote:\n> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:\n>> Hi Rafał,\n>>\n>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>> From: Rafał Miłecki \n>>>\n>>> Some LEDs can be related to particular devices described in DT. This\n>>> property allows specifying such relations. E.g. USB LED should usually\n>>> be used to indicate some USB port(s) state.\n>>>\n>>> Signed-off-by: Rafał Miłecki \n>>> ---\n>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>> allows specifying other devices as well.\n>>>\n>>> When bindings patch is related to some followup implementation, they usually go\n>>> through the same tree.\n>>>\n>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>> released?\n>>> ---\n>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>> 1 file changed, 16 insertions(+)\n>>>\n>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>> index 24b656014089..17632a041196 100644\n>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>> - panic-indicator : This property specifies that the LED should be used,\n>>> \t\t if at all possible, as a panic indicator.\n>>> \n>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>> +\t\t LEDs can be related to a specific device and should somehow\n>>> +\t\t indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>> +\t\t a USB 2.0 port(s). Another common example is switch or router\n>>> +\t\t with multiple Ethernet ports each of them having its own LED\n>>> +\t\t assigned (assuminled-trigger-usbportg they are not hardwired).\n>>> +\t\t In such cases this property should contain phandle(s) of\n>>> +\t\t related device(s). In many cases LED can be related to more\n>>> +\t\t than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>> +\t\t list of entries can be specified.\n>>> +\n>>\n>> This implies that it is possible to define multiple triggers for\n>> a LED class device but it is not supported by LED Trigger core.\n> \n> Not really relevant for designing (and future proofing) a binding.\n\nBut relevant for LED Trigger ABI, which would have to be changed to\nsupport the semantics in this form. I think that changing the property\nname to linux,trigger-sources would make its purpose more clear.\n\nNote that we have to also associate somehow this property with the\ntriggers that will make use of the information it provides. I can\nimagine also other compound triggers that could benefit on it.\n\nWhat follows, the trigger sources would trigger LED activity only\nif the LED class device was assigned appropriate trigger. We need to\ndefine somewhere which triggers support this property.\n\nTrigger specific bindings?\n\n>> There is linux,default-trigger property which allows to define one\n>> trigger that will be initially assigned.\n>>\n>> I am aware that this is renamed usb-ports property from v1,\n>> that attempts to address Rob's comment, but we can't do that this way.\n>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>> specific bindings and a reference to it could be added next to the\n>> related entry on the list of the available LED triggers (which is\n>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n> \n> I'm not going to accept something specific to USB. So the choice is make \n> the existing property work for USB or design something more flexible and \n> generic.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v6k5y1kL0z9sR9\n\tfor ;\n\tTue, 24 Jan 2017 07:52:38 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751508AbdAWUwg (ORCPT\n\t);\n\tMon, 23 Jan 2017 15:52:36 -0500","from mail-wm0-f67.google.com ([74.125.82.67]:35453 \"EHLO\n\tmail-wm0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750957AbdAWUwf (ORCPT\n\t); Mon, 23 Jan 2017 15:52:35 -0500","by mail-wm0-f67.google.com with SMTP id d140so29358493wmd.2;\n\tMon, 23 Jan 2017 12:52:34 -0800 (PST)","from [192.168.1.17] (bme8.neoplus.adsl.tpnet.pl. [83.28.224.8])\n\tby smtp.gmail.com with ESMTPSA id\n\t204sm22936949wmj.7.2017.01.23.12.52.31\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 23 Jan 2017 12:52:32 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"jG8tp9ZX\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=fo9rtpotv+8uDlW/nhRv5J7w1s2T81vWbOZWF5R0Cj8=;\n\tb=jG8tp9ZXuYydtuoDIhv+/RNrm3VndK19TsmbyELFaZ1tV88N1QTS30KqdrKJf1+Qn4\n\theURq2lmr+Qz9A4aInp8lxdvsmerYc9D6YM6o53RmkgguIsFOCNG9TCBrKaXhBY/3QOT\n\tfH2XOhsDdAhtECcJyN07KXZePUhFQ3Upo0jUNNURkkV6zPl9XOENF3RT7GtkeuKLzmco\n\tLXu/qOh2Hr0uHgpoGoaPKw1Db13BVgwqYTBPJMgKvZsjKrkSwH1WFw7enKpJXslKZ+Xp\n\tYdrcGJYjS7JQfBP/VOnOc8h8SiCjQrpeds00itePDufPG5bGYejqJ3k9qGVT3mLT1/cQ\n\towOA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=fo9rtpotv+8uDlW/nhRv5J7w1s2T81vWbOZWF5R0Cj8=;\n\tb=W+uwdDDpuNPds9b8A3rE9Q/EgmsR9nKzcOI57z9DdSoBQxKybuFYEOTCd0XkEIjP/n\n\tMpw1U1FdT4/W5mzl23sIhLwZcZ1jDv8xzKyQ5GirCVe6rDEy4hxN4FzUm7QHRBNNI4Q2\n\tdz7UUTXp3IEUDEZ6nLN1wQUbGXV4rOXhiEua6vT7rstW2KZ7aa2xxSvPDRhXbEB4kBJh\n\t2doDC9FeIwduV+aQBvyfHOlsts2PEu4uXWrGKxpbhEI9A8BiAa3UA90NSOS/DeEkVi9b\n\tYbLt+71s+xiWejJmO19/ixAibjmlRCi3w4Wgy1oCpEfR5lzlK2GuzLQeKYl/ki270plF\n\tBIwA==","X-Gm-Message-State":"AIkVDXLpgB4prR+ii8L8T6sQwotq8pES5O1uClBXPVOSE5LQEIPo6nuML1uKiG8h3WImWA==","X-Received":"by 10.223.129.163 with SMTP id 32mr24739037wra.140.1485204753521;\n\tMon, 23 Jan 2017 12:52:33 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Rob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>","Cc":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tGreg Kroah-Hartman ,\n\tlinux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tMark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"","Date":"Mon, 23 Jan 2017 21:51:49 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1565006,"web_url":"http://patchwork.ozlabs.org/comment/1565006/","msgid":"","list_archive_url":null,"date":"2017-01-25T09:03:34","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 21 January 2017 at 22:42, Jacek Anaszewski\n wrote:\n> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>> wrote:\n>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>> From: Rafał Miłecki \n>>>>\n>>>> Some LEDs can be related to particular devices described in DT. This\n>>>> property allows specifying such relations. E.g. USB LED should usually\n>>>> be used to indicate some USB port(s) state.\n>>>>\n>>>> Signed-off-by: Rafał Miłecki \n>>>> ---\n>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>>> allows specifying other devices as well.\n>>>>\n>>>> When bindings patch is related to some followup implementation, they usually go\n>>>> through the same tree.\n>>>>\n>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>>> released?\n>>>> ---\n>>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>>> 1 file changed, 16 insertions(+)\n>>>>\n>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>>> index 24b656014089..17632a041196 100644\n>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>> - panic-indicator : This property specifies that the LED should be used,\n>>>> if at all possible, as a panic indicator.\n>>>>\n>>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>>> + LEDs can be related to a specific device and should somehow\n>>>> + indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>>> + a USB 2.0 port(s). Another common example is switch or router\n>>>> + with multiple Ethernet ports each of them having its own LED\n>>>> + assigned (assuminled-trigger-usbportg they are not hardwired).\n>>>> + In such cases this property should contain phandle(s) of\n>>>> + related device(s). In many cases LED can be related to more\n>>>> + than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>>> + list of entries can be specified.\n>>>> +\n>>>\n>>> This implies that it is possible to define multiple triggers for\n>>> a LED class device but it is not supported by LED Trigger core.\n>>> There is linux,default-trigger property which allows to define one\n>>> trigger that will be initially assigned.\n>\n>> With proposed \"led-triggers\" property one could assign different\n>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n>> device & CPU to a single LED. For reason explained above Linux\n>> couldn't support all of them at once.\n>>\n>>\n>>> I am aware that this is renamed usb-ports property from v1,\n>>> that attempts to address Rob's comment, but we can't do that this way.\n>>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>>> specific bindings and a reference to it could be added next to the\n>>> related entry on the list of the available LED triggers (which is\n>>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n>>\n>> I'm wondering if we need to care about this Linux limitation and if it\n>> should stop us from adding this flexible DT property. Maybe we could\n>> live with Linux having limitation of supporting one trigger type at a\n>> time?\n>\n> That's what I meant. Generally I have objections to the generic\n> property for defining list of allowed triggers. That's why I proposed\n> to stay by usb-ports property that would be specific to only one\n> trigger: led-trigger-usbport.\n>\n> led-trigger-usbport in fact is an entirely new type of LED trigger.\n> LED triggers is a kernel based source of events. All existing triggers\n> react only to a single, well defined source of events, whereas\n> led-trigger-usbport allows to define the scope of events (usb ports)\n> to notify about. Activity on each port is treated similarly and the LED\n> class device that listens to the trigger notifications doesn't know\n> which exact port triggered the notification.\n>\n> From this POV led-trigger-usbport is kind of facade, which allows\n> for it to fit well into the LED Trigger design and API, and usb ports\n> are not identical with LED triggers, but sit rather one level below.\n> It is led-trigger-usbport which is visible to the LED subsystem, and\n> not every single usb port.\n\nI of course agree with your nice usbport trigger driver summary.\n\n\n> Therefore it isn't logically justified to rename usb-ports property\n> to led-triggers. The property should be specific to this trigger.\n\nOnly if you mean to limit this property to the usbport trigger driver.\nRob wants to have this property cover other cases and I mean to work\non more trigger drivers using it as well. So I hope we can look at a\nbigger picture focusing on a nice design that will allow reusing this\nproperty in other places.\n\nI'd like to work on netdev / netif / netiface trigger driver in the\nfuture. I was going to use this DT property there as well.\n\nSorry, I should have make it clear from the beginning I mean to re-use\n\"led-triggers\" in other trigger drivers as well.\n\n\n>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>> decides to use \"usport\" trigger driver he'll get LED indicating status\n>> of USB ports only.\n>\n> How would it be different from the current state? Only in limiting\n> the scope of triggers available for a LED class device.\n\nIt won't differ from the current state. I just wanted to make it clear\nLinux trigger drivers may respect only selected \"led-triggers\" values\n(phandles). Like \"usbport\" respecting USB port phandles but ignoring\nCPU ones, net ones, etc.\n\n\n>> I think we could live with such limitation in Linux support for this\n>> generic \"led-triggers\" property. I think it's also not very common to\n>> have LED with different types of devices assigned. Personally I've\n>> never seen devices with LED label \"USB & CPU\" or whatever.\n>\n> I agree. Nonetheless led-triggers seems to support such a design.\n\nThat's right. DT property \"led-triggers\" supports by design more than\nLinux drivers can handle right now. That was my main point of this\ne-mail.\n\n\n>> What do you think about this? Maybe we could also document this\n>> limitation in trigger docs.\n>\n> I'm not entirely sure if I got your point. Your reasoning seems\n> self contradicting to me in few places.\n\nI'm sorry, I obviously had to fail at some point explaining my idea.\nLet's see if this e-mail made it clearer.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v7fHM1ZGVz9ryk\n\tfor ;\n\tWed, 25 Jan 2017 20:03:59 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751360AbdAYJDm (ORCPT\n\t);\n\tWed, 25 Jan 2017 04:03:42 -0500","from mail-oi0-f67.google.com ([209.85.218.67]:35502 \"EHLO\n\tmail-oi0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751332AbdAYJDg (ORCPT\n\t); Wed, 25 Jan 2017 04:03:36 -0500","by mail-oi0-f67.google.com with SMTP id x84so15127525oix.2;\n\tWed, 25 Jan 2017 01:03:36 -0800 (PST)","by 10.202.237.3 with HTTP; Wed, 25 Jan 2017 01:03:34 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"dqJXDL2L\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc:content-transfer-encoding;\n\tbh=CuB+wfyA6GGWYkf/7bh7b1hr6ORIBcw5oo+TgKtaZXI=;\n\tb=dqJXDL2LxYF2ZrlaJBt9KdBH22VRY/o6BNkcphCmW5pmucpehgN3UFG+6ApT5vjtx/\n\tmCfSPsptrPsElpwO3DHgKeEAekuRAKT0OiJeImIvU891/bKb/ytxRSBOVPR853wG+B2G\n\tugXu3CMGTU15RU9lCx9q1P9qK/nkKOzyJZ25RgmWhQn/BcQN3E5TDGTLal5NXBQLfz4O\n\t+xjJYWBpzb+IY2qi2WOd1INLlEV7QJDCpBnV5yPwPT28HLLKN6makjHwIeGir/xxBw9o\n\tPKz9UoKSIZmNZ6bCN39VB14aH+LrmNJ5eIW8BCOviFVCzV1V6fFsx4qEfS+2//ktCQ7I\n\tQo9A==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc:content-transfer-encoding;\n\tbh=CuB+wfyA6GGWYkf/7bh7b1hr6ORIBcw5oo+TgKtaZXI=;\n\tb=In25qXU2DkHGz4tZTZsN6dlYue7y3QmTJ52gghg8rrEC9ZqCSknSGS9Js/o9wexeq5\n\tIS1w+znFcQBl8vZSL/sJiE3a0T21MUDbF5H4s/qExIC4B198SBziv325gyBAWM2ACAe9\n\trMacaPNqqHldrecDTe/d3LJRUSUWu1+ecR8ns+l4087k3dyL9yIrtksJxIj82usvdtIg\n\tnKk99cYEPSK9vnjkc6M6GD6zU4C0X++mNlsQeAnfXL87+nHscLUxYg0NukAvyIDqfw+d\n\tuhJQ9aZgf3kDTFBXqwEEDgLVNNHcJ27ZDiezpnFyOM9g7g1eSbDPVpp0sy3WZfFbddAU\n\tyARg==","X-Gm-Message-State":"AIkVDXJGrjBmCYjqkS4HjqElzKUz8EpBjur6NK+CMInlQiaqa+VyBosAyVZqyX1n/aBG4LDd0i2vSRbBrSa4Sw==","X-Received":"by 10.202.191.5 with SMTP id p5mr11043423oif.197.1485335014853; \n\tWed, 25 Jan 2017 01:03:34 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Date":"Wed, 25 Jan 2017 10:03:34 +0100","Message-ID":"","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"quoted-printable","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1565010,"web_url":"http://patchwork.ozlabs.org/comment/1565010/","msgid":"","list_archive_url":null,"date":"2017-01-25T09:08:59","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 01/23/2017 05:45 PM, Rob Herring wrote:\n> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:\n>> Hi Rafał,\n>>\n>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>> From: Rafał Miłecki \n>>>\n>>> Some LEDs can be related to particular devices described in DT. This\n>>> property allows specifying such relations. E.g. USB LED should usually\n>>> be used to indicate some USB port(s) state.\n>>>\n>>> Signed-off-by: Rafał Miłecki \n>>> ---\n>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>> allows specifying other devices as well.\n>>>\n>>> When bindings patch is related to some followup implementation, they usually go\n>>> through the same tree.\n>>>\n>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>> released?\n>>> ---\n>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>> 1 file changed, 16 insertions(+)\n>>>\n>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>> index 24b656014089..17632a041196 100644\n>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>> - panic-indicator : This property specifies that the LED should be used,\n>>> \t\t if at all possible, as a panic indicator.\n>>>\n>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>> +\t\t LEDs can be related to a specific device and should somehow\n>>> +\t\t indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>> +\t\t a USB 2.0 port(s). Another common example is switch or router\n>>> +\t\t with multiple Ethernet ports each of them having its own LED\n>>> +\t\t assigned (assuminled-trigger-usbportg they are not hardwired).\n>>> +\t\t In such cases this property should contain phandle(s) of\n>>> +\t\t related device(s). In many cases LED can be related to more\n>>> +\t\t than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>> +\t\t list of entries can be specified.\n>>> +\n>>\n>> This implies that it is possible to define multiple triggers for\n>> a LED class device but it is not supported by LED Trigger core.\n>\n> Not really relevant for designing (and future proofing) a binding.\n\nThis is what I really like in this \"led-triggers\" property: it's future proof. I\nwill be able to reuse it in other trigger drivers and I won't be trying to sneak\nproperties like\n* usb-port-triggers\n* net-interface-triggers\n* cpu-triggers\netc.\n\nSaying that thanks Rob for rejecting my initial \"usb-ports\" property try :P\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v7fQ953H7z9sXx\n\tfor ;\n\tWed, 25 Jan 2017 20:09:53 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751360AbdAYJJv (ORCPT\n\t);\n\tWed, 25 Jan 2017 04:09:51 -0500","from mail-lf0-f65.google.com ([209.85.215.65]:36433 \"EHLO\n\tmail-lf0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751260AbdAYJJr (ORCPT\n\t); Wed, 25 Jan 2017 04:09:47 -0500","by mail-lf0-f65.google.com with SMTP id h65so19775158lfi.3;\n\tWed, 25 Jan 2017 01:09:02 -0800 (PST)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233])\n\tby smtp.googlemail.com with ESMTPSA id\n\tb7sm7063970lfe.33.2017.01.25.01.08.59\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 25 Jan 2017 01:09:00 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"o5/98wck\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=ADLlv061EN60w5IB76tJ3hUEBsd5B8gQzDwdXryEDSU=;\n\tb=o5/98wck16zIgrx2ntpCxj6okRMuDbeGfyK6+4ETQXm95KqgZZ7TAtiUckDxTKTjaG\n\tKgjSydOEK2bMt+L2xd02t8kUIAtSkrbX0imxf/j12ZNIvDPgvzaON16lDvSg6wexA0y/\n\tcjfmCGERM95rt0apIGlLEKQx9/q+PpGetqGBG0hqRZfzfiK2kS1Lvn9xBSLmuzPjEIWZ\n\tQg/YVHmLS9CSUf0PhYvrzx7bB2TTqRp9CyY8UF6QbfCrwAblkZQv0QWfC8VWBjRXyIuL\n\tT3jSZq/GU3lZXen3fxkAdeRH7dqj3bLbFp2ZzVDl4D0OtWwRTGBEIWUjpmsuJgEEkW/Q\n\tVNkQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=ADLlv061EN60w5IB76tJ3hUEBsd5B8gQzDwdXryEDSU=;\n\tb=c+E7peAJH9SiUrnU3PD66vEBnX/EQoqhNYLcS7mmUNqJYqXDBLACcds9nBrbsPrSAs\n\txO0a5XnQEJkV/4l0xOBXE/tT34X0zO55u6rrQeH1AU1G7mS+Ql2jLpMqTqzXlf4igS+g\n\tMtDrUOV5qNOVyYJJhHPiY+PruF80ZziZouHn0SwMDB9XdqeX/1Wi++wRUe6FTn6LGLv4\n\tp5ZsbMvXL1brWsQRHjt4IzhR6KTIuJDecZKNaQjr0F1KIit9aiA24uj1M3ClroUjVMxt\n\tddDcAbGQGv21GwvvTe/0Y5t0aS9c5M3RRi7gWnAfPtWDIEycQTzT0ljNCm8wG6XRSMOs\n\tKMcw==","X-Gm-Message-State":"AIkVDXIn7fT2EqwsaC/9+OX2taWMQ9juoW/2eKzxr3ORprzN3QNsmprZtm9GlA7B28FGyw==","X-Received":"by 10.46.20.25 with SMTP id u25mr15706199ljd.61.1485335340852;\n\tWed, 25 Jan 2017 01:09:00 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Rob Herring ,\n\tJacek Anaszewski ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>","Cc":"Greg Kroah-Hartman ,\n\tlinux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tMark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"","Date":"Wed, 25 Jan 2017 10:08:59 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1565018,"web_url":"http://patchwork.ozlabs.org/comment/1565018/","msgid":"<2aed99c3-7ebe-8b16-5d75-8d0d5b20c27e@gmail.com>","list_archive_url":null,"date":"2017-01-25T09:18:06","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 01/23/2017 09:51 PM, Jacek Anaszewski wrote:\n> On 01/23/2017 05:45 PM, Rob Herring wrote:\n>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:\n>>> Hi Rafał,\n>>>\n>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>> From: Rafał Miłecki \n>>>>\n>>>> Some LEDs can be related to particular devices described in DT. This\n>>>> property allows specifying such relations. E.g. USB LED should usually\n>>>> be used to indicate some USB port(s) state.\n>>>>\n>>>> Signed-off-by: Rafał Miłecki \n>>>> ---\n>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>>> allows specifying other devices as well.\n>>>>\n>>>> When bindings patch is related to some followup implementation, they usually go\n>>>> through the same tree.\n>>>>\n>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>>> released?\n>>>> ---\n>>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>>> 1 file changed, 16 insertions(+)\n>>>>\n>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>>> index 24b656014089..17632a041196 100644\n>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>> - panic-indicator : This property specifies that the LED should be used,\n>>>> \t\t if at all possible, as a panic indicator.\n>>>>\n>>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>>> +\t\t LEDs can be related to a specific device and should somehow\n>>>> +\t\t indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>>> +\t\t a USB 2.0 port(s). Another common example is switch or router\n>>>> +\t\t with multiple Ethernet ports each of them having its own LED\n>>>> +\t\t assigned (assuminled-trigger-usbportg they are not hardwired).\n>>>> +\t\t In such cases this property should contain phandle(s) of\n>>>> +\t\t related device(s). In many cases LED can be related to more\n>>>> +\t\t than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>>> +\t\t list of entries can be specified.\n>>>> +\n>>>\n>>> This implies that it is possible to define multiple triggers for\n>>> a LED class device but it is not supported by LED Trigger core.\n>>\n>> Not really relevant for designing (and future proofing) a binding.\n>\n> But relevant for LED Trigger ABI, which would have to be changed to\n> support the semantics in this form. I think that changing the property\n> name to linux,trigger-sources would make its purpose more clear.\n>\n> Note that we have to also associate somehow this property with the\n> triggers that will make use of the information it provides. I can\n> imagine also other compound triggers that could benefit on it.\n>\n> What follows, the trigger sources would trigger LED activity only\n> if the LED class device was assigned appropriate trigger. We need to\n> define somewhere which triggers support this property.\n>\n> Trigger specific bindings?\n\nMaybe this is something I'm missing. Why adding this \"led-triggers\" property\nwould mean/require ABI breakage?\n\nAFAIU adding support for \"led-triggers\" to the \"usbport\" trigger driver (see\npatch 2/2) didn't break anything, I hope?\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v7fcF1kCGz9svs\n\tfor ;\n\tWed, 25 Jan 2017 20:18:37 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751425AbdAYJSe (ORCPT\n\t);\n\tWed, 25 Jan 2017 04:18:34 -0500","from mail-lf0-f65.google.com ([209.85.215.65]:35671 \"EHLO\n\tmail-lf0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751376AbdAYJSK (ORCPT\n\t); Wed, 25 Jan 2017 04:18:10 -0500","by mail-lf0-f65.google.com with SMTP id v186so19918350lfa.2;\n\tWed, 25 Jan 2017 01:18:09 -0800 (PST)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233])\n\tby smtp.googlemail.com with ESMTPSA id\n\tt126sm8329846lff.31.2017.01.25.01.18.06\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 25 Jan 2017 01:18:07 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"urQzyaGs\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=2gUjmL+VVWMwRdeSLjFMDVIYtUwk7panZJOr7KPiER8=;\n\tb=urQzyaGsk4ACazJPQABAI07rg6HmCJDh/ZqpY356R4haIvr0uQSESqsNPjKWKNntZr\n\tl2imyzvPARi++dTZ99w48MQzdVCcpdt3l/Wsm+dfgJy8ApaazJpn58ZzjhU+WCrpzK9L\n\t+IfHnoyxqI9NhLblTPirKfUJ3kieTHihOBfunv48WoRbzuW18H0Bx3bY55s9jtJ1C8At\n\t0hNG9YwNY/BZNuSCFUylf7UW/+eLOAJmMChcHlwOaP8AKqMjk0cZOB7SXrX2YRHCMOYV\n\tL0Y+1nWpvR4TIFVPDw1j5AWzkEb+s99JwGm9jOs3pHeZY3L7UlAuGLaV4IxXpH6Ux+bu\n\tImMg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=2gUjmL+VVWMwRdeSLjFMDVIYtUwk7panZJOr7KPiER8=;\n\tb=bYXeCjtVsATsnBui67mTTP2f529Ib+j0pKyT4XiNWBdTjCY8v4zHl5Se4KVXCqe+f/\n\tZGTxknybcZUYFbCstA7kuAc+zi0M0qOekmugER55N9PRrQyCLwaLAJm7ciMlKlz1pnoJ\n\tVpy3K7sYe10+NHZ/SyiKkxBRBWaBoGA5yV243Swk69v4hzY5jYeaSTGgps6iAFftxy+a\n\tPp3JGW4MRgxptkHORCeTYxT6A3YzNg2hRoqVoB9yxWuCX9crC3C4QLiDaNbcetnWPbmw\n\tVy2K0rhAAMdHEAwhzN3yv+RrrIZMVxe9o7zRlyF7LkFmcCZyS1/mvEXMlDQhyvN6nmEG\n\tcmlQ==","X-Gm-Message-State":"AIkVDXJ0jCJyYrnVslrOweTodp6NGLRlzHGlR2OPImZuPNzW4kyCqdtpCu24JVGEjQrV0g==","X-Received":"by 10.46.9.20 with SMTP id 20mr15749131ljj.0.1485335888081;\n\tWed, 25 Jan 2017 01:18:08 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>\n\t","Cc":"Greg Kroah-Hartman ,\n\tlinux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tMark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"<2aed99c3-7ebe-8b16-5d75-8d0d5b20c27e@gmail.com>","Date":"Wed, 25 Jan 2017 10:18:06 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1565687,"web_url":"http://patchwork.ozlabs.org/comment/1565687/","msgid":"<64edcff2-6dcb-66ea-ab36-cc7a6db523d9@gmail.com>","list_archive_url":null,"date":"2017-01-25T21:04:09","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 01/25/2017 10:18 AM, Rafał Miłecki wrote:\n> On 01/23/2017 09:51 PM, Jacek Anaszewski wrote:\n>> On 01/23/2017 05:45 PM, Rob Herring wrote:\n>>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:\n>>>> Hi Rafał,\n>>>>\n>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>> From: Rafał Miłecki \n>>>>>\n>>>>> Some LEDs can be related to particular devices described in DT. This\n>>>>> property allows specifying such relations. E.g. USB LED should usually\n>>>>> be used to indicate some USB port(s) state.\n>>>>>\n>>>>> Signed-off-by: Rafał Miłecki \n>>>>> ---\n>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more\n>>>>> generic and\n>>>>> allows specifying other devices as well.\n>>>>>\n>>>>> When bindings patch is related to some followup implementation,\n>>>>> they usually go\n>>>>> through the same tree.\n>>>>>\n>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds:\n>>>>> Improve examples by\n>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git .\n>>>>> Is there any\n>>>>> way to solve this dependency issue? Or should this patch wait until\n>>>>> 3.11 is\n>>>>> released?\n>>>>> ---\n>>>>> Documentation/devicetree/bindings/leds/common.txt | 16\n>>>>> ++++++++++++++++\n>>>>> 1 file changed, 16 insertions(+)\n>>>>>\n>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt\n>>>>> b/Documentation/devicetree/bindings/leds/common.txt\n>>>>> index 24b656014089..17632a041196 100644\n>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>> - panic-indicator : This property specifies that the LED should be\n>>>>> used,\n>>>>> if at all possible, as a panic indicator.\n>>>>>\n>>>>> +- led-triggers : List of devices that should trigger this LED\n>>>>> activity. Some\n>>>>> + LEDs can be related to a specific device and should somehow\n>>>>> + indicate its state. E.g. USB 2.0 LED may react to\n>>>>> device(s) in\n>>>>> + a USB 2.0 port(s). Another common example is switch or\n>>>>> router\n>>>>> + with multiple Ethernet ports each of them having its own LED\n>>>>> + assigned (assuminled-trigger-usbportg they are not\n>>>>> hardwired).\n>>>>> + In such cases this property should contain phandle(s) of\n>>>>> + related device(s). In many cases LED can be related to more\n>>>>> + than one device (e.g. one USB LED vs. multiple USB ports)\n>>>>> so a\n>>>>> + list of entries can be specified.\n>>>>> +\n>>>>\n>>>> This implies that it is possible to define multiple triggers for\n>>>> a LED class device but it is not supported by LED Trigger core.\n>>>\n>>> Not really relevant for designing (and future proofing) a binding.\n>>\n>> But relevant for LED Trigger ABI, which would have to be changed to\n>> support the semantics in this form. I think that changing the property\n>> name to linux,trigger-sources would make its purpose more clear.\n>>\n>> Note that we have to also associate somehow this property with the\n>> triggers that will make use of the information it provides. I can\n>> imagine also other compound triggers that could benefit on it.\n>>\n>> What follows, the trigger sources would trigger LED activity only\n>> if the LED class device was assigned appropriate trigger. We need to\n>> define somewhere which triggers support this property.\n>>\n>> Trigger specific bindings?\n> \n> Maybe this is something I'm missing. Why adding this \"led-triggers\"\n> property\n> would mean/require ABI breakage?\n\nAs I explained in the other message, LED Triggers are drivers registered\nin the LED Trigger core. LED subsystem allows for only one active\ntrigger at a time (triggers sysfs file reports selected trigger by\nwrapping its name with square brackets on the space separated list\nof all available LED Triggers).\n\nThe problem is in the property name, which can easily lead to wrong\nconclusions for the reader not familiar with the LED Trigger core\ndesign.\n\n> AFAIU adding support for \"led-triggers\" to the \"usbport\" trigger driver\n> (see\n> patch 2/2) didn't break anything, I hope?\n> \n\nNo, it didn't, but ambiguity in the documentation can lead to\nmisunderstanding and hinder learning LED subsystem API.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v7yHH4pQmz9srY\n\tfor ;\n\tThu, 26 Jan 2017 08:04:59 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751374AbdAYVE5 (ORCPT\n\t);\n\tWed, 25 Jan 2017 16:04:57 -0500","from mail-wm0-f68.google.com ([74.125.82.68]:33227 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750930AbdAYVEz (ORCPT\n\t); Wed, 25 Jan 2017 16:04:55 -0500","by mail-wm0-f68.google.com with SMTP id r144so45387356wme.0;\n\tWed, 25 Jan 2017 13:04:54 -0800 (PST)","from [192.168.1.17] (bku143.neoplus.adsl.tpnet.pl. [83.28.188.143])\n\tby smtp.gmail.com with ESMTPSA id\n\td42sm26721979wrd.7.2017.01.25.13.04.51\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 25 Jan 2017 13:04:52 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"UQRETqO6\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=DcwM+TofcIx8LqFhjOj9r8eSDBj+xahmasysg6utkvE=;\n\tb=UQRETqO6JuQUvgxX09bYRbn/Opj+PrN6zUWv2gwGsCwCYWKqKsM7Aj3Yf2T1b6P2MV\n\tVAY9eaikCaAqOKwdbQXTGjGMRQVnRvv7cjvCKVc5EO096YlLKl68PeiPsd7PCbtrzl2y\n\t+b3ih5z5qstOkzOCU/AYeoNprHw//rKtAO8lRXb60dFRK8BizqQaNWrXtHYAAcaNh6Qp\n\tOcA6ceiNHpwAnMTw4vaXHq25EjtewF0JfiQX1ONXRePRUPKiR+/2aoAAjfNMYhsO0i2B\n\tdpVPu73kXbgG+mlrVDJR6jKm5WCIFgPnqHq+e/1RuUksSgDIAQMaHUR8ISfELS8IrvWY\n\txzCA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=DcwM+TofcIx8LqFhjOj9r8eSDBj+xahmasysg6utkvE=;\n\tb=eSHu6LG7wbuEbVDC2gRSBtmwCSlJXNJBox3RBOl9FgWBoFdGO3W9Cb2v7Sel4Dggq+\n\t2OPsHQ+5NQeRMABHv2ki6DgKviOxFLaYOu9Ioa7wDLR+E2pZ10AGmrsk0+lAafc6dn9d\n\tUcgqYk0P+Eoe5rFSaIylx52k9pOwFdwo8nErosUZPW6y86hASrN9suio2hoOKd6EEW7R\n\tUSwV7bsa5/zRldvxQ0BWPHJBsGrcH7y0h7KvlcPD+P+Gz/1f3qyc6V2hdAy2vwtXX/OY\n\t9fpPsVzewCgGj8TpYmG5YvwyCwYmCBm3WQ/wFhkpEHey7jZ5f59HyTevaJFfx3ZvB/5c\n\tE6UA==","X-Gm-Message-State":"AIkVDXLhL8yXJrRi6hh7612Uz+tpHGAjeP0+QPp8kry8Q0M1NLh0JL/iHrjx+a+A/KY8rA==","X-Received":"by 10.28.234.66 with SMTP id i63mr25397221wmh.43.1485378293404; \n\tWed, 25 Jan 2017 13:04:53 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>\n\t\n\t<2aed99c3-7ebe-8b16-5d75-8d0d5b20c27e@gmail.com>","Cc":"Greg Kroah-Hartman ,\n\tlinux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tMark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<64edcff2-6dcb-66ea-ab36-cc7a6db523d9@gmail.com>","Date":"Wed, 25 Jan 2017 22:04:09 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"<2aed99c3-7ebe-8b16-5d75-8d0d5b20c27e@gmail.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1565688,"web_url":"http://patchwork.ozlabs.org/comment/1565688/","msgid":"","list_archive_url":null,"date":"2017-01-25T21:04:04","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 01/25/2017 10:03 AM, Rafał Miłecki wrote:\n> On 21 January 2017 at 22:42, Jacek Anaszewski\n> wrote:\n>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>>> wrote:\n>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>> From: Rafał Miłecki \n>>>>>\n>>>>> Some LEDs can be related to particular devices described in DT. This\n>>>>> property allows specifying such relations. E.g. USB LED should usually\n>>>>> be used to indicate some USB port(s) state.\n>>>>>\n>>>>> Signed-off-by: Rafał Miłecki \n>>>>> ---\n>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>>>> allows specifying other devices as well.\n>>>>>\n>>>>> When bindings patch is related to some followup implementation, they usually go\n>>>>> through the same tree.\n>>>>>\n>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>>>> released?\n>>>>> ---\n>>>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>>>> 1 file changed, 16 insertions(+)\n>>>>>\n>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>>>> index 24b656014089..17632a041196 100644\n>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>> - panic-indicator : This property specifies that the LED should be used,\n>>>>> if at all possible, as a panic indicator.\n>>>>>\n>>>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>>>> + LEDs can be related to a specific device and should somehow\n>>>>> + indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>>>> + a USB 2.0 port(s). Another common example is switch or router\n>>>>> + with multiple Ethernet ports each of them having its own LED\n>>>>> + assigned (assuminled-trigger-usbportg they are not hardwired).\n>>>>> + In such cases this property should contain phandle(s) of\n>>>>> + related device(s). In many cases LED can be related to more\n>>>>> + than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>>>> + list of entries can be specified.\n>>>>> +\n>>>>\n>>>> This implies that it is possible to define multiple triggers for\n>>>> a LED class device but it is not supported by LED Trigger core.\n>>>> There is linux,default-trigger property which allows to define one\n>>>> trigger that will be initially assigned.\n>>\n>>> With proposed \"led-triggers\" property one could assign different\n>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n>>> device & CPU to a single LED. For reason explained above Linux\n>>> couldn't support all of them at once.\n>>>\n>>>\n>>>> I am aware that this is renamed usb-ports property from v1,\n>>>> that attempts to address Rob's comment, but we can't do that this way.\n>>>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>>>> specific bindings and a reference to it could be added next to the\n>>>> related entry on the list of the available LED triggers (which is\n>>>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n>>>\n>>> I'm wondering if we need to care about this Linux limitation and if it\n>>> should stop us from adding this flexible DT property. Maybe we could\n>>> live with Linux having limitation of supporting one trigger type at a\n>>> time?\n>>\n>> That's what I meant. Generally I have objections to the generic\n>> property for defining list of allowed triggers. That's why I proposed\n>> to stay by usb-ports property that would be specific to only one\n>> trigger: led-trigger-usbport.\n>>\n>> led-trigger-usbport in fact is an entirely new type of LED trigger.\n>> LED triggers is a kernel based source of events. All existing triggers\n>> react only to a single, well defined source of events, whereas\n>> led-trigger-usbport allows to define the scope of events (usb ports)\n>> to notify about. Activity on each port is treated similarly and the LED\n>> class device that listens to the trigger notifications doesn't know\n>> which exact port triggered the notification.\n>>\n>> From this POV led-trigger-usbport is kind of facade, which allows\n>> for it to fit well into the LED Trigger design and API, and usb ports\n>> are not identical with LED triggers, but sit rather one level below.\n>> It is led-trigger-usbport which is visible to the LED subsystem, and\n>> not every single usb port.\n> \n> I of course agree with your nice usbport trigger driver summary.\n> \n> \n>> Therefore it isn't logically justified to rename usb-ports property\n>> to led-triggers. The property should be specific to this trigger.\n> \n> Only if you mean to limit this property to the usbport trigger driver.\n> Rob wants to have this property cover other cases and I mean to work\n> on more trigger drivers using it as well. So I hope we can look at a\n> bigger picture focusing on a nice design that will allow reusing this\n> property in other places.\n> \n> I'd like to work on netdev / netif / netiface trigger driver in the\n> future. I was going to use this DT property there as well.\n> \n> Sorry, I should have make it clear from the beginning I mean to re-use\n> \"led-triggers\" in other trigger drivers as well.\n> \n> \n>>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>>> decides to use \"usport\" trigger driver he'll get LED indicating status\n>>> of USB ports only.\n>>\n>> How would it be different from the current state? Only in limiting\n>> the scope of triggers available for a LED class device.\n> \n> It won't differ from the current state. I just wanted to make it clear\n> Linux trigger drivers may respect only selected \"led-triggers\" values\n> (phandles). Like \"usbport\" respecting USB port phandles but ignoring\n> CPU ones, net ones, etc.\n\nThis is the ambiguity I want to avoid. According to my analysis from\nthe previous message, physical usb port is one level below usbport LED\ntrigger, and it should be reflected in DT binding documentation. You\ncan't write usb1-port1 (using the convention from Documentation/leds/\nledtrig-usbport.txt) to the \"triggers\" sysfs file. You can only register\nusbport trigger which can be configured to notify about activity on\nusb1-port1.\n\nThat's why I proposed linux,trigger-sources name for that.\nLet's not confuse LED triggers with events originating from physical\ndevices or other sources of kernel events, being in turn translated by\nLED triggers to LED brightness changes.\n\nThis is a thing about naming. It is tempting to call sources of kernel\nevents \"triggers\", but they are not LED triggers on they own. LED\ntrigger is a driver that registers itself in LED Trigger core using\nled_trigger_register() API.\n\n>>> I think we could live with such limitation in Linux support for this\n>>> generic \"led-triggers\" property. I think it's also not very common to\n>>> have LED with different types of devices assigned. Personally I've\n>>> never seen devices with LED label \"USB & CPU\" or whatever.\n>>\n>> I agree. Nonetheless led-triggers seems to support such a design.\n> \n> That's right. DT property \"led-triggers\" supports by design more than\n> Linux drivers can handle right now. That was my main point of this\n> e-mail.\n\nHaving my above explanation, I see your led-triggers property as a means\nfor limiting the scope of LED Triggers available for a LED class\ndevice. Physical usb port, not being a trigger on its own, wouldn't\nfall into this category.\n\n>>> What do you think about this? Maybe we could also document this\n>>> limitation in trigger docs.\n>>\n>> I'm not entirely sure if I got your point. Your reasoning seems\n>> self contradicting to me in few places.\n> \n> I'm sorry, I obviously had to fail at some point explaining my idea.\n> Let's see if this e-mail made it clearer.\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v7yHJ3dlrz9t0G\n\tfor ;\n\tThu, 26 Jan 2017 08:05:00 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750930AbdAYVE6 (ORCPT\n\t);\n\tWed, 25 Jan 2017 16:04:58 -0500","from mail-wm0-f68.google.com ([74.125.82.68]:33155 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751202AbdAYVEz (ORCPT\n\t); Wed, 25 Jan 2017 16:04:55 -0500","by mail-wm0-f68.google.com with SMTP id r144so45386858wme.0;\n\tWed, 25 Jan 2017 13:04:49 -0800 (PST)","from [192.168.1.17] (bku143.neoplus.adsl.tpnet.pl. [83.28.188.143])\n\tby smtp.gmail.com with ESMTPSA id\n\to143sm385661wmd.3.2017.01.25.13.04.46\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 25 Jan 2017 13:04:47 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"rm/7AEM0\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=V+HI2ICu7/TBaht9uZHOoO7HKX2hg93LeTmF9wWly0I=;\n\tb=rm/7AEM00p0ADUp5EItWiO766Apjh9lPrtjK2qiv3jSFtC9HstqC8C++7bpmFPPHRn\n\thc/65o5bwAJPgB00PTaU6HxJh1439psQxoCpUOT861seqycL+SM3ASnv1lL5KmY94HxT\n\tO4iJ0IN/IIiPFn2HuXtjXJQNtDaOdw7EfeqctCUm/7BZ7KOVDAoInSRRnU2qJLzhP/SX\n\tzr4AcB7ES6xn0C/5CHSkDbhnFnzAteSixaVJ58d3DSn5kcuHWu7g54Kp6UH9k3qsOJfd\n\t4vInh7Cgsmlnc983x72TVETT6mFp+eMKlTIumA9H/kdJfDCc52aWhV8w3wEwGozeI7xU\n\t7BHw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=V+HI2ICu7/TBaht9uZHOoO7HKX2hg93LeTmF9wWly0I=;\n\tb=U+xUJLhMDZ0h/r3sdzKCJo9lPviuVDWyL/iS3NVqiUpyEEr84Q0Sx/Lkrgv+GxLtkf\n\tiqwO+UzULzXRiwNz2xQ0BtFKxEqnIJ6PNcaLvMDErARdyXP4OdvElb4yvYF/4elLg3u6\n\tCv84sXIuhcIaTMg5v50hPXF51O9VdMqHIuiew68w2gnnVKrCcZQ7wH643QrTQNd1721C\n\tGtDw92eMsgoXbZ4i8jIuybO5v0eB4yx9WEwijnjRr3szm++2VyFUkObbWf9vcaq6jroy\n\t0eqU/O9U51YjY6pFPhNjq6R0LhPKIhV4d3REA39e1GVJozKCRpVwJK2nv9Zqrx1638fN\n\tX10Q==","X-Gm-Message-State":"AIkVDXKMSNuvtxPbWDgkHVUuuo8ukeanGliQotRUkI68vS+fEGB1YozkKdg/VnmAh9N6WA==","X-Received":"by 10.223.151.135 with SMTP id s7mr33944565wrb.51.1485378288501; \n\tWed, 25 Jan 2017 13:04:48 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"","Date":"Wed, 25 Jan 2017 22:04:04 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1565689,"web_url":"http://patchwork.ozlabs.org/comment/1565689/","msgid":"<377e69a2-b474-517a-3013-f980ab4ff2cb@gmail.com>","list_archive_url":null,"date":"2017-01-25T21:04:06","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 01/25/2017 10:08 AM, Rafał Miłecki wrote:\n> On 01/23/2017 05:45 PM, Rob Herring wrote:\n>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:\n>>> Hi Rafał,\n>>>\n>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>> From: Rafał Miłecki \n>>>>\n>>>> Some LEDs can be related to particular devices described in DT. This\n>>>> property allows specifying such relations. E.g. USB LED should usually\n>>>> be used to indicate some USB port(s) state.\n>>>>\n>>>> Signed-off-by: Rafał Miłecki \n>>>> ---\n>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more\n>>>> generic and\n>>>> allows specifying other devices as well.\n>>>>\n>>>> When bindings patch is related to some followup implementation, they\n>>>> usually go\n>>>> through the same tree.\n>>>>\n>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve\n>>>> examples by\n>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git .\n>>>> Is there any\n>>>> way to solve this dependency issue? Or should this patch wait until\n>>>> 3.11 is\n>>>> released?\n>>>> ---\n>>>> Documentation/devicetree/bindings/leds/common.txt | 16\n>>>> ++++++++++++++++\n>>>> 1 file changed, 16 insertions(+)\n>>>>\n>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt\n>>>> b/Documentation/devicetree/bindings/leds/common.txt\n>>>> index 24b656014089..17632a041196 100644\n>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>> - panic-indicator : This property specifies that the LED should be\n>>>> used,\n>>>> if at all possible, as a panic indicator.\n>>>>\n>>>> +- led-triggers : List of devices that should trigger this LED\n>>>> activity. Some\n>>>> + LEDs can be related to a specific device and should somehow\n>>>> + indicate its state. E.g. USB 2.0 LED may react to\n>>>> device(s) in\n>>>> + a USB 2.0 port(s). Another common example is switch or router\n>>>> + with multiple Ethernet ports each of them having its own LED\n>>>> + assigned (assuminled-trigger-usbportg they are not\n>>>> hardwired).\n>>>> + In such cases this property should contain phandle(s) of\n>>>> + related device(s). In many cases LED can be related to more\n>>>> + than one device (e.g. one USB LED vs. multiple USB ports)\n>>>> so a\n>>>> + list of entries can be specified.\n>>>> +\n>>>\n>>> This implies that it is possible to define multiple triggers for\n>>> a LED class device but it is not supported by LED Trigger core.\n>>\n>> Not really relevant for designing (and future proofing) a binding.\n> \n> This is what I really like in this \"led-triggers\" property: it's future\n> proof. I\n> will be able to reuse it in other trigger drivers and I won't be trying\n> to sneak\n> properties like\n> * usb-port-triggers\n> * net-interface-triggers\n> * cpu-triggers\n> etc.\n\nVery well, but led-triggers in this approach are not LED trigger drivers\nbut sources of events. Therefore I proposed trigger-sources.\n\n> Saying that thanks Rob for rejecting my initial \"usb-ports\" property try :P\n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3v7yHM3Xh0z9sCg\n\tfor ;\n\tThu, 26 Jan 2017 08:05:03 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751803AbdAYVFC (ORCPT\n\t);\n\tWed, 25 Jan 2017 16:05:02 -0500","from mail-wm0-f65.google.com ([74.125.82.65]:35830 \"EHLO\n\tmail-wm0-f65.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751515AbdAYVE5 (ORCPT\n\t); Wed, 25 Jan 2017 16:04:57 -0500","by mail-wm0-f65.google.com with SMTP id d140so45518767wmd.2;\n\tWed, 25 Jan 2017 13:04:56 -0800 (PST)","from [192.168.1.17] (bku143.neoplus.adsl.tpnet.pl. [83.28.188.143])\n\tby smtp.gmail.com with ESMTPSA id\n\ty1sm352539wme.15.2017.01.25.13.04.48\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 25 Jan 2017 13:04:49 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"slXNxcyd\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=JIPCtbzSQeiQrmTckRjtEiMqJuE+g/VmgIyhnFhzpJg=;\n\tb=slXNxcydJniNXeQLud5LXIXccauEhQ0Gy0454WVXuosSXH4LlhEazhTa5nWqnOAXzJ\n\tp802MgQuR5jsDW7lhu1vwmp5AfwxzLO+ePXl7IGxMXFx7D83PiCKKSCv5mxNpx0Jz15l\n\txlk9Q4hRb5m9kK7T33AlWDEpmwdfgePuEHGbJL3OQGsmCnfS29l0c7YYp6vzZopsccQU\n\tT/cPazraFHCvVOU82M9AdYBXK35CPy9eDnHksBNp386Ke2nMIgTCSSSIYTEPkhA9yAGS\n\tzuucwN1Q0lunLRwTD1d69edqAzXi/Li/zWSX/YFGZTIFm2kgpt4Uukmc7H5/osiPi3BU\n\tnauw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=JIPCtbzSQeiQrmTckRjtEiMqJuE+g/VmgIyhnFhzpJg=;\n\tb=uGL1Gh8P1U+01TNxNqVoD+UrhF3XXoxMtuDHilZDwzQZiJimpWsPzLxekEb16Oa85L\n\tGYBpII+bG6DhmdraNX2U7I0S5wLjEuLMhim2RXmCnV9CnlvZIrR/K5tHyyK9sxNw0y9r\n\txj5rpU+Ju1SEbIlDlZHcZlbFlMSegdZK7kwuLvmfelSXfGObv2PABtzMbfQazhcU75hc\n\tsHUJRS7fIBNs/DnB/tdJraTCa/t71r8ArsgeRyF0jiML3VAsd22Y9VEg1KqPoRv/ZBf6\n\tUb3+Onz0K5pe/B0TtwR0jLffb5IdyZ6atySShn9JG9wx9SCbGx98TNjiS4DHJD9nuuEb\n\tz3fQ==","X-Gm-Message-State":"AIkVDXLKqfRPM7LKjKjatq41hSJ40A8BBc984Yp1iZuD7205QiET8zpeLchUgT4l5e3GjA==","X-Received":"by 10.28.220.135 with SMTP id t129mr26349061wmg.97.1485378290278;\n\tWed, 25 Jan 2017 13:04:50 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t<20170123164537.ldq6de64adjkefbr@rob-hp-laptop>\n\t","Cc":"Greg Kroah-Hartman ,\n\tlinux-usb@vger.kernel.org, linux-leds@vger.kernel.org,\n\tRichard Purdie ,\n\tPavel Machek , devicetree@vger.kernel.org,\n\tMark Rutland ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<377e69a2-b474-517a-3013-f980ab4ff2cb@gmail.com>","Date":"Wed, 25 Jan 2017 22:04:06 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1570749,"web_url":"http://patchwork.ozlabs.org/comment/1570749/","msgid":"","list_archive_url":null,"date":"2017-01-31T16:11:43","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":70180,"url":"http://patchwork.ozlabs.org/api/people/70180/","name":"Rafał Miłecki","email":"rafal@milecki.pl"},"content":"On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:\n> On 01/25/2017 10:03 AM, Rafał Miłecki wrote:\n>> On 21 January 2017 at 22:42, Jacek Anaszewski\n>> wrote:\n>>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>>>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>>>> wrote:\n>>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>>> From: Rafał Miłecki \n>>>>>>\n>>>>>> Some LEDs can be related to particular devices described in DT. This\n>>>>>> property allows specifying such relations. E.g. USB LED should usually\n>>>>>> be used to indicate some USB port(s) state.\n>>>>>>\n>>>>>> Signed-off-by: Rafał Miłecki \n>>>>>> ---\n>>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is more generic and\n>>>>>> allows specifying other devices as well.\n>>>>>>\n>>>>>> When bindings patch is related to some followup implementation, they usually go\n>>>>>> through the same tree.\n>>>>>>\n>>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds: Improve examples by\n>>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git . Is there any\n>>>>>> way to solve this dependency issue? Or should this patch wait until 3.11 is\n>>>>>> released?\n>>>>>> ---\n>>>>>> Documentation/devicetree/bindings/leds/common.txt | 16 ++++++++++++++++\n>>>>>> 1 file changed, 16 insertions(+)\n>>>>>>\n>>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>> index 24b656014089..17632a041196 100644\n>>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>>> - panic-indicator : This property specifies that the LED should be used,\n>>>>>> if at all possible, as a panic indicator.\n>>>>>>\n>>>>>> +- led-triggers : List of devices that should trigger this LED activity. Some\n>>>>>> + LEDs can be related to a specific device and should somehow\n>>>>>> + indicate its state. E.g. USB 2.0 LED may react to device(s) in\n>>>>>> + a USB 2.0 port(s). Another common example is switch or router\n>>>>>> + with multiple Ethernet ports each of them having its own LED\n>>>>>> + assigned (assuminled-trigger-usbportg they are not hardwired).\n>>>>>> + In such cases this property should contain phandle(s) of\n>>>>>> + related device(s). In many cases LED can be related to more\n>>>>>> + than one device (e.g. one USB LED vs. multiple USB ports) so a\n>>>>>> + list of entries can be specified.\n>>>>>> +\n>>>>>\n>>>>> This implies that it is possible to define multiple triggers for\n>>>>> a LED class device but it is not supported by LED Trigger core.\n>>>>> There is linux,default-trigger property which allows to define one\n>>>>> trigger that will be initially assigned.\n>>>\n>>>> With proposed \"led-triggers\" property one could assign different\n>>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n>>>> device & CPU to a single LED. For reason explained above Linux\n>>>> couldn't support all of them at once.\n>>>>\n>>>>\n>>>>> I am aware that this is renamed usb-ports property from v1,\n>>>>> that attempts to address Rob's comment, but we can't do that this way.\n>>>>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>>>>> specific bindings and a reference to it could be added next to the\n>>>>> related entry on the list of the available LED triggers (which is\n>>>>> actually missing) in Documentation/devicetree/bindings/leds/common.txt.\n>>>>\n>>>> I'm wondering if we need to care about this Linux limitation and if it\n>>>> should stop us from adding this flexible DT property. Maybe we could\n>>>> live with Linux having limitation of supporting one trigger type at a\n>>>> time?\n>>>\n>>> That's what I meant. Generally I have objections to the generic\n>>> property for defining list of allowed triggers. That's why I proposed\n>>> to stay by usb-ports property that would be specific to only one\n>>> trigger: led-trigger-usbport.\n>>>\n>>> led-trigger-usbport in fact is an entirely new type of LED trigger.\n>>> LED triggers is a kernel based source of events. All existing triggers\n>>> react only to a single, well defined source of events, whereas\n>>> led-trigger-usbport allows to define the scope of events (usb ports)\n>>> to notify about. Activity on each port is treated similarly and the LED\n>>> class device that listens to the trigger notifications doesn't know\n>>> which exact port triggered the notification.\n>>>\n>>> From this POV led-trigger-usbport is kind of facade, which allows\n>>> for it to fit well into the LED Trigger design and API, and usb ports\n>>> are not identical with LED triggers, but sit rather one level below.\n>>> It is led-trigger-usbport which is visible to the LED subsystem, and\n>>> not every single usb port.\n>>>\n>>>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>>>> decides to use \"usport\" trigger driver he'll get LED indicating status\n>>>> of USB ports only.\n>>>\n>>> How would it be different from the current state? Only in limiting\n>>> the scope of triggers available for a LED class device.\n>>\n>> It won't differ from the current state. I just wanted to make it clear\n>> Linux trigger drivers may respect only selected \"led-triggers\" values\n>> (phandles). Like \"usbport\" respecting USB port phandles but ignoring\n>> CPU ones, net ones, etc.\n>\n> This is the ambiguity I want to avoid. According to my analysis from\n> the previous message, physical usb port is one level below usbport LED\n> trigger, and it should be reflected in DT binding documentation. You\n> can't write usb1-port1 (using the convention from Documentation/leds/\n> ledtrig-usbport.txt) to the \"triggers\" sysfs file. You can only register\n> usbport trigger which can be configured to notify about activity on\n> usb1-port1.\n>\n> That's why I proposed linux,trigger-sources name for that.\n> Let's not confuse LED triggers with events originating from physical\n> devices or other sources of kernel events, being in turn translated by\n> LED triggers to LED brightness changes.\n>\n> This is a thing about naming. It is tempting to call sources of kernel\n> events \"triggers\", but they are not LED triggers on they own. LED\n> trigger is a driver that registers itself in LED Trigger core using\n> led_trigger_register() API.\n\nThanks a lot Jacek for this explanation (and sorry but I needed a bit of time to\nthink about this). I can finally see your point, I think we're on the same page\nnow.\n\nI think that for all this time I was thinking from the pure DT perspective. If\nyou ignore fact that Linux has multiple LED trigger drivers, then \"led-triggers\"\nmay not sound that bad.\n\nAfter reading your description however I can see this property can be misleading\nas Linux people may think \"drivers\" when seeing \"triggers\".\n\nI still think this is a useful property and I hope we can still find a way to\nname it in a sane way: to be nice from DT PoV and march Linux LEDs subsystem.\n\nI think we should still work on some generic property (without linux, prefix) as\nthis seems to be something generic, not really specific to Linux implementation.\nSpecifying relation between LED and devices is something than AFAICS can be\nreused by other systems as well.\n\nSo my suggestion is to try some new name & leave linux,default-trigger to allow\nspecifying one single trigger driver as required by current Linux\nimplementation.\n\nWhat do you think about this?\n\nThere are few suggestions to came to my mind:\n\"trigger-sources\"\n\"trigger-devices\"\n\"led-trigger-devices\"\n\"led-related-devices\"\n\"led-event-devices\"\nDo you think any of them would work? Or can you think of any better name?\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vCb480jsRz9ry7\n\tfor ;\n\tWed, 1 Feb 2017 05:52:56 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751632AbdAaSv0 (ORCPT\n\t);\n\tTue, 31 Jan 2017 13:51:26 -0500","from 1.mo1.mail-out.ovh.net ([178.32.127.22]:35908 \"EHLO\n\t1.mo1.mail-out.ovh.net\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751459AbdAaSvW (ORCPT\n\t); Tue, 31 Jan 2017 13:51:22 -0500","from player169.ha.ovh.net (b9.ovh.net [213.186.33.59])\n\tby mo1.mail-out.ovh.net (Postfix) with ESMTP id 10E694D58F\n\tfor ;\n\tTue, 31 Jan 2017 17:12:00 +0100 (CET)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl [194.187.74.233])\n\t(Authenticated sender: rafal@milecki.pl)\n\tby player169.ha.ovh.net (Postfix) with ESMTPSA id 29CE35800B0;\n\tTue, 31 Jan 2017 17:11:44 +0100 (CET)"],"X-Greylist":"delayed 9544 seconds by postgrey-1.27 at vger.kernel.org;\n\tTue, 31 Jan 2017 13:51:21 EST","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"","Date":"Tue, 31 Jan 2017 17:11:43 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","X-Ovh-Tracer-Id":"13207931811191230001","X-VR-SPAMSTATE":"OK","X-VR-SPAMSCORE":"-100","X-VR-SPAMCAUSE":"gggruggvucftvghtrhhoucdtuddrfeelgedrieehgdekiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1570924,"web_url":"http://patchwork.ozlabs.org/comment/1570924/","msgid":"","list_archive_url":null,"date":"2017-01-31T21:34:02","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"Hi Rafał,\n\nOn 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:\n>> On 01/25/2017 10:03 AM, Rafał Miłecki wrote:\n>>> On 21 January 2017 at 22:42, Jacek Anaszewski\n>>> wrote:\n>>>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>>>>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>>>>> wrote:\n>>>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>>>> From: Rafał Miłecki \n>>>>>>>\n>>>>>>> Some LEDs can be related to particular devices described in DT. This\n>>>>>>> property allows specifying such relations. E.g. USB LED should\n>>>>>>> usually\n>>>>>>> be used to indicate some USB port(s) state.\n>>>>>>>\n>>>>>>> Signed-off-by: Rafał Miłecki \n>>>>>>> ---\n>>>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is\n>>>>>>> more generic and\n>>>>>>> allows specifying other devices as well.\n>>>>>>>\n>>>>>>> When bindings patch is related to some followup implementation,\n>>>>>>> they usually go\n>>>>>>> through the same tree.\n>>>>>>>\n>>>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds:\n>>>>>>> Improve examples by\n>>>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git\n>>>>>>> . Is there any\n>>>>>>> way to solve this dependency issue? Or should this patch wait\n>>>>>>> until 3.11 is\n>>>>>>> released?\n>>>>>>> ---\n>>>>>>> Documentation/devicetree/bindings/leds/common.txt | 16\n>>>>>>> ++++++++++++++++\n>>>>>>> 1 file changed, 16 insertions(+)\n>>>>>>>\n>>>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>> b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>> index 24b656014089..17632a041196 100644\n>>>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>>>> - panic-indicator : This property specifies that the LED should\n>>>>>>> be used,\n>>>>>>> if at all possible, as a panic indicator.\n>>>>>>>\n>>>>>>> +- led-triggers : List of devices that should trigger this LED\n>>>>>>> activity. Some\n>>>>>>> + LEDs can be related to a specific device and\n>>>>>>> should somehow\n>>>>>>> + indicate its state. E.g. USB 2.0 LED may react to\n>>>>>>> device(s) in\n>>>>>>> + a USB 2.0 port(s). Another common example is\n>>>>>>> switch or router\n>>>>>>> + with multiple Ethernet ports each of them having\n>>>>>>> its own LED\n>>>>>>> + assigned (assuminled-trigger-usbportg they are not\n>>>>>>> hardwired).\n>>>>>>> + In such cases this property should contain\n>>>>>>> phandle(s) of\n>>>>>>> + related device(s). In many cases LED can be\n>>>>>>> related to more\n>>>>>>> + than one device (e.g. one USB LED vs. multiple USB\n>>>>>>> ports) so a\n>>>>>>> + list of entries can be specified.\n>>>>>>> +\n>>>>>>\n>>>>>> This implies that it is possible to define multiple triggers for\n>>>>>> a LED class device but it is not supported by LED Trigger core.\n>>>>>> There is linux,default-trigger property which allows to define one\n>>>>>> trigger that will be initially assigned.\n>>>>\n>>>>> With proposed \"led-triggers\" property one could assign different\n>>>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n>>>>> device & CPU to a single LED. For reason explained above Linux\n>>>>> couldn't support all of them at once.\n>>>>>\n>>>>>\n>>>>>> I am aware that this is renamed usb-ports property from v1,\n>>>>>> that attempts to address Rob's comment, but we can't do that this\n>>>>>> way.\n>>>>>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>>>>>> specific bindings and a reference to it could be added next to the\n>>>>>> related entry on the list of the available LED triggers (which is\n>>>>>> actually missing) in\n>>>>>> Documentation/devicetree/bindings/leds/common.txt.\n>>>>>\n>>>>> I'm wondering if we need to care about this Linux limitation and if it\n>>>>> should stop us from adding this flexible DT property. Maybe we could\n>>>>> live with Linux having limitation of supporting one trigger type at a\n>>>>> time?\n>>>>\n>>>> That's what I meant. Generally I have objections to the generic\n>>>> property for defining list of allowed triggers. That's why I proposed\n>>>> to stay by usb-ports property that would be specific to only one\n>>>> trigger: led-trigger-usbport.\n>>>>\n>>>> led-trigger-usbport in fact is an entirely new type of LED trigger.\n>>>> LED triggers is a kernel based source of events. All existing triggers\n>>>> react only to a single, well defined source of events, whereas\n>>>> led-trigger-usbport allows to define the scope of events (usb ports)\n>>>> to notify about. Activity on each port is treated similarly and the LED\n>>>> class device that listens to the trigger notifications doesn't know\n>>>> which exact port triggered the notification.\n>>>>\n>>>> From this POV led-trigger-usbport is kind of facade, which allows\n>>>> for it to fit well into the LED Trigger design and API, and usb ports\n>>>> are not identical with LED triggers, but sit rather one level below.\n>>>> It is led-trigger-usbport which is visible to the LED subsystem, and\n>>>> not every single usb port.\n>>>>\n>>>>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>>>>> decides to use \"usport\" trigger driver he'll get LED indicating status\n>>>>> of USB ports only.\n>>>>\n>>>> How would it be different from the current state? Only in limiting\n>>>> the scope of triggers available for a LED class device.\n>>>\n>>> It won't differ from the current state. I just wanted to make it clear\n>>> Linux trigger drivers may respect only selected \"led-triggers\" values\n>>> (phandles). Like \"usbport\" respecting USB port phandles but ignoring\n>>> CPU ones, net ones, etc.\n>>\n>> This is the ambiguity I want to avoid. According to my analysis from\n>> the previous message, physical usb port is one level below usbport LED\n>> trigger, and it should be reflected in DT binding documentation. You\n>> can't write usb1-port1 (using the convention from Documentation/leds/\n>> ledtrig-usbport.txt) to the \"triggers\" sysfs file. You can only register\n>> usbport trigger which can be configured to notify about activity on\n>> usb1-port1.\n>>\n>> That's why I proposed linux,trigger-sources name for that.\n>> Let's not confuse LED triggers with events originating from physical\n>> devices or other sources of kernel events, being in turn translated by\n>> LED triggers to LED brightness changes.\n>>\n>> This is a thing about naming. It is tempting to call sources of kernel\n>> events \"triggers\", but they are not LED triggers on they own. LED\n>> trigger is a driver that registers itself in LED Trigger core using\n>> led_trigger_register() API.\n> \n> Thanks a lot Jacek for this explanation (and sorry but I needed a bit of\n> time to\n> think about this). I can finally see your point, I think we're on the\n> same page\n> now.\n> \n> I think that for all this time I was thinking from the pure DT\n> perspective. If\n> you ignore fact that Linux has multiple LED trigger drivers, then\n> \"led-triggers\"\n> may not sound that bad.\n> \n> After reading your description however I can see this property can be\n> misleading\n> as Linux people may think \"drivers\" when seeing \"triggers\".\n> \n> I still think this is a useful property and I hope we can still find a\n> way to\n> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n> subsystem.\n\nI also see the need for this property.\n\n> I think we should still work on some generic property (without linux,\n> prefix) as\n> this seems to be something generic, not really specific to Linux\n> implementation.\n> Specifying relation between LED and devices is something than AFAICS can be\n> reused by other systems as well.\n> \n> So my suggestion is to try some new name & leave linux,default-trigger\n> to allow\n> specifying one single trigger driver as required by current Linux\n> implementation.\n> \n> What do you think about this?\n> \n> There are few suggestions to came to my mind:\n> \"trigger-sources\"\n> \"trigger-devices\"\n> \"led-trigger-devices\"\n> \"led-related-devices\"\n> \"led-event-devices\"\n\ntrigger-devices would work in this specific use case,\nwhere we can give phandles to usb ports. Nonetheless, we\nhave also other kernel based events serving as trigger\nsources - e.g. timer.\n\nIn this case I'd go for trigger-sources, but we'd need\nto have some generic way of defining the source like timer.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vCfh86bBdz9svs\n\tfor ;\n\tWed, 1 Feb 2017 08:35:52 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750727AbdAaVft (ORCPT\n\t);\n\tTue, 31 Jan 2017 16:35:49 -0500","from mail-wm0-f66.google.com ([74.125.82.66]:33105 \"EHLO\n\tmail-wm0-f66.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750726AbdAaVfq (ORCPT\n\t); Tue, 31 Jan 2017 16:35:46 -0500","by mail-wm0-f66.google.com with SMTP id v77so1107411wmv.0;\n\tTue, 31 Jan 2017 13:34:51 -0800 (PST)","from [192.168.1.17] (dnt247.neoplus.adsl.tpnet.pl. [83.24.101.247])\n\tby smtp.gmail.com with ESMTPSA id\n\te14sm25911760wmd.14.2017.01.31.13.34.48\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 31 Jan 2017 13:34:49 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"uypivm8U\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=32hm6Y3aVlx4Co3cC6MNd+d3Aq0Nl6tH7/PN/9+ZKTM=;\n\tb=uypivm8UgCq4Ht5Fcvgu+lkDZYvpHK2e3z5XGNEZuAN+rmiywVmRp5bmw/OmYZXJn9\n\tsLh2N4If97T7XAqEhJnA3XjcUD8DkdbqZ8c5JLCVsvB6pD9ifvHTDY75pk3YLmGkdhH4\n\tY6FtOC2tisQuqaz7ofcluqMHN5AgQg8vg2pQY2/a4PLtKfyrJR/vixvIJRdWtOOaLHtb\n\tiYpOt1/JriG/6o5iqJSz5qJpSyxS2x/VYAkUD71X23cpO+PDN0/K4UMV8aWXLySrSiKZ\n\t4imhQfH1smjUCcMZswYPjWQAtPkpOWU/GpNXxAluuStjRbWm98EWjHVtwx4IkUkNmH4z\n\tcUpQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=32hm6Y3aVlx4Co3cC6MNd+d3Aq0Nl6tH7/PN/9+ZKTM=;\n\tb=NUVY+hLHxmTwaZzwEJKotwuMJ28crDORC+M7ebbiDkavT9FEwmk6ojPIklqcVBy//5\n\thzKTaD7adj1hG3NA48cleOHLUT5hSEdbGF4c466jxHpNqz6Y/kcee2Hb/RpjPacPM5+3\n\tgcc6pFGqJ9nXCWThnDx6oAW2Zjez4InVL54swnbTTK0zs5RiXjZZoQBaMpUIFNBkjk0W\n\tIhugikELGxPeMprIOKSF1pb0HzAGPnKUUMAW5W/EaBvKHtgC5iVOSseinNOnu7sMSpiX\n\t0PqG3UXDSP67F53Fp0OPJdv4qDGM3doflRnS3hqUupZt9w20PSd7qGjiQQVBhPhZI287\n\tZStw==","X-Gm-Message-State":"AIkVDXKqkN6W9w1HgwEWeGKz4bgQv2FOKdh25YiC1ACHW3jrygTTleZKRhZkmUH4fgc3eg==","X-Received":"by 10.28.113.9 with SMTP id m9mr21437525wmc.60.1485898490444;\n\tTue, 31 Jan 2017 13:34:50 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"","Date":"Tue, 31 Jan 2017 22:34:02 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1571189,"web_url":"http://patchwork.ozlabs.org/comment/1571189/","msgid":"","list_archive_url":null,"date":"2017-02-01T07:38:48","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:\n>>> On 01/25/2017 10:03 AM, Rafał Miłecki wrote:\n>>>> On 21 January 2017 at 22:42, Jacek Anaszewski\n>>>> wrote:\n>>>>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>>>>>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>>>>>> wrote:\n>>>>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>>>>> From: Rafał Miłecki \n>>>>>>>>\n>>>>>>>> Some LEDs can be related to particular devices described in DT. This\n>>>>>>>> property allows specifying such relations. E.g. USB LED should\n>>>>>>>> usually\n>>>>>>>> be used to indicate some USB port(s) state.\n>>>>>>>>\n>>>>>>>> Signed-off-by: Rafał Miłecki \n>>>>>>>> ---\n>>>>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is\n>>>>>>>> more generic and\n>>>>>>>> allows specifying other devices as well.\n>>>>>>>>\n>>>>>>>> When bindings patch is related to some followup implementation,\n>>>>>>>> they usually go\n>>>>>>>> through the same tree.\n>>>>>>>>\n>>>>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds:\n>>>>>>>> Improve examples by\n>>>>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git\n>>>>>>>> . Is there any\n>>>>>>>> way to solve this dependency issue? Or should this patch wait\n>>>>>>>> until 3.11 is\n>>>>>>>> released?\n>>>>>>>> ---\n>>>>>>>> Documentation/devicetree/bindings/leds/common.txt | 16\n>>>>>>>> ++++++++++++++++\n>>>>>>>> 1 file changed, 16 insertions(+)\n>>>>>>>>\n>>>>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> index 24b656014089..17632a041196 100644\n>>>>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>>>>> - panic-indicator : This property specifies that the LED should\n>>>>>>>> be used,\n>>>>>>>> if at all possible, as a panic indicator.\n>>>>>>>>\n>>>>>>>> +- led-triggers : List of devices that should trigger this LED\n>>>>>>>> activity. Some\n>>>>>>>> + LEDs can be related to a specific device and\n>>>>>>>> should somehow\n>>>>>>>> + indicate its state. E.g. USB 2.0 LED may react to\n>>>>>>>> device(s) in\n>>>>>>>> + a USB 2.0 port(s). Another common example is\n>>>>>>>> switch or router\n>>>>>>>> + with multiple Ethernet ports each of them having\n>>>>>>>> its own LED\n>>>>>>>> + assigned (assuminled-trigger-usbportg they are not\n>>>>>>>> hardwired).\n>>>>>>>> + In such cases this property should contain\n>>>>>>>> phandle(s) of\n>>>>>>>> + related device(s). In many cases LED can be\n>>>>>>>> related to more\n>>>>>>>> + than one device (e.g. one USB LED vs. multiple USB\n>>>>>>>> ports) so a\n>>>>>>>> + list of entries can be specified.\n>>>>>>>> +\n>>>>>>>\n>>>>>>> This implies that it is possible to define multiple triggers for\n>>>>>>> a LED class device but it is not supported by LED Trigger core.\n>>>>>>> There is linux,default-trigger property which allows to define one\n>>>>>>> trigger that will be initially assigned.\n>>>>>\n>>>>>> With proposed \"led-triggers\" property one could assign different\n>>>>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n>>>>>> device & CPU to a single LED. For reason explained above Linux\n>>>>>> couldn't support all of them at once.\n>>>>>>\n>>>>>>\n>>>>>>> I am aware that this is renamed usb-ports property from v1,\n>>>>>>> that attempts to address Rob's comment, but we can't do that this\n>>>>>>> way.\n>>>>>>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>>>>>>> specific bindings and a reference to it could be added next to the\n>>>>>>> related entry on the list of the available LED triggers (which is\n>>>>>>> actually missing) in\n>>>>>>> Documentation/devicetree/bindings/leds/common.txt.\n>>>>>>\n>>>>>> I'm wondering if we need to care about this Linux limitation and if it\n>>>>>> should stop us from adding this flexible DT property. Maybe we could\n>>>>>> live with Linux having limitation of supporting one trigger type at a\n>>>>>> time?\n>>>>>\n>>>>> That's what I meant. Generally I have objections to the generic\n>>>>> property for defining list of allowed triggers. That's why I proposed\n>>>>> to stay by usb-ports property that would be specific to only one\n>>>>> trigger: led-trigger-usbport.\n>>>>>\n>>>>> led-trigger-usbport in fact is an entirely new type of LED trigger.\n>>>>> LED triggers is a kernel based source of events. All existing triggers\n>>>>> react only to a single, well defined source of events, whereas\n>>>>> led-trigger-usbport allows to define the scope of events (usb ports)\n>>>>> to notify about. Activity on each port is treated similarly and the LED\n>>>>> class device that listens to the trigger notifications doesn't know\n>>>>> which exact port triggered the notification.\n>>>>>\n>>>>> From this POV led-trigger-usbport is kind of facade, which allows\n>>>>> for it to fit well into the LED Trigger design and API, and usb ports\n>>>>> are not identical with LED triggers, but sit rather one level below.\n>>>>> It is led-trigger-usbport which is visible to the LED subsystem, and\n>>>>> not every single usb port.\n>>>>>\n>>>>>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>>>>>> decides to use \"usport\" trigger driver he'll get LED indicating status\n>>>>>> of USB ports only.\n>>>>>\n>>>>> How would it be different from the current state? Only in limiting\n>>>>> the scope of triggers available for a LED class device.\n>>>>\n>>>> It won't differ from the current state. I just wanted to make it clear\n>>>> Linux trigger drivers may respect only selected \"led-triggers\" values\n>>>> (phandles). Like \"usbport\" respecting USB port phandles but ignoring\n>>>> CPU ones, net ones, etc.\n>>>\n>>> This is the ambiguity I want to avoid. According to my analysis from\n>>> the previous message, physical usb port is one level below usbport LED\n>>> trigger, and it should be reflected in DT binding documentation. You\n>>> can't write usb1-port1 (using the convention from Documentation/leds/\n>>> ledtrig-usbport.txt) to the \"triggers\" sysfs file. You can only register\n>>> usbport trigger which can be configured to notify about activity on\n>>> usb1-port1.\n>>>\n>>> That's why I proposed linux,trigger-sources name for that.\n>>> Let's not confuse LED triggers with events originating from physical\n>>> devices or other sources of kernel events, being in turn translated by\n>>> LED triggers to LED brightness changes.\n>>>\n>>> This is a thing about naming. It is tempting to call sources of kernel\n>>> events \"triggers\", but they are not LED triggers on they own. LED\n>>> trigger is a driver that registers itself in LED Trigger core using\n>>> led_trigger_register() API.\n>>\n>> Thanks a lot Jacek for this explanation (and sorry but I needed a bit of\n>> time to\n>> think about this). I can finally see your point, I think we're on the\n>> same page\n>> now.\n>>\n>> I think that for all this time I was thinking from the pure DT\n>> perspective. If\n>> you ignore fact that Linux has multiple LED trigger drivers, then\n>> \"led-triggers\"\n>> may not sound that bad.\n>>\n>> After reading your description however I can see this property can be\n>> misleading\n>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>\n>> I still think this is a useful property and I hope we can still find a\n>> way to\n>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>> subsystem.\n>\n> I also see the need for this property.\n>\n>> I think we should still work on some generic property (without linux,\n>> prefix) as\n>> this seems to be something generic, not really specific to Linux\n>> implementation.\n>> Specifying relation between LED and devices is something than AFAICS can be\n>> reused by other systems as well.\n>>\n>> So my suggestion is to try some new name & leave linux,default-trigger\n>> to allow\n>> specifying one single trigger driver as required by current Linux\n>> implementation.\n>>\n>> What do you think about this?\n>>\n>> There are few suggestions to came to my mind:\n>> \"trigger-sources\"\n>> \"trigger-devices\"\n>> \"led-trigger-devices\"\n>> \"led-related-devices\"\n>> \"led-event-devices\"\n>\n> trigger-devices would work in this specific use case,\n> where we can give phandles to usb ports. Nonetheless, we\n> have also other kernel based events serving as trigger\n> sources - e.g. timer.\n>\n> In this case I'd go for trigger-sources, but we'd need\n> to have some generic way of defining the source like timer.\n\nOK, let's try \"trigger-sources\" then!\n\nI'll rename this property and send V3 with hopefully a better description.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vCw4702V3z9t2D\n\tfor ;\n\tWed, 1 Feb 2017 18:39:00 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751302AbdBAHi6 (ORCPT\n\t);\n\tWed, 1 Feb 2017 02:38:58 -0500","from mail-lf0-f67.google.com ([209.85.215.67]:34425 \"EHLO\n\tmail-lf0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751080AbdBAHi5 (ORCPT\n\t); Wed, 1 Feb 2017 02:38:57 -0500","by mail-lf0-f67.google.com with SMTP id q89so35726002lfi.1;\n\tTue, 31 Jan 2017 23:38:56 -0800 (PST)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233])\n\tby smtp.googlemail.com with ESMTPSA id\n\tc2sm5458206ljb.24.2017.01.31.23.38.48\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 31 Jan 2017 23:38:49 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"sSx4/O2L\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=4tslroHI4CTq6CSBjv8sICqlUOj2hyQE2AK8uQBqYBY=;\n\tb=sSx4/O2LTL3tM1nWea1hYSxQ5/p7Ttpzt3+nuABnlGM2Rvv336cq9TL9leA2xg1Prv\n\tMMEfpPVcX9zj8UwifjhgRSjP0Mpoyj/EN4+tfIlL0KsyYt26s9AIrmH6+k8zN7fhgGnd\n\tr+z3Trld6JrqfbrdkotfQinqe4/+WNriShFeKIKt9b3sEsFGOPwFM3mT3Zhd09shztTX\n\tpxiKl4SNyYcK3aXvOCu46RrRW7CcmhxeXAHfTiAGdy7crRFpjCN2+pOQVpc7ih/wLXZ1\n\t9QpbKWRiY50u7SLm7Qfgq1pQmLPSp0sXk27do6amxmntKdi0n1zxZsG15/lZb02wUiUt\n\tfZFg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=4tslroHI4CTq6CSBjv8sICqlUOj2hyQE2AK8uQBqYBY=;\n\tb=q1YI/jo3n28NP3UT8c1Eqk80OGTVc7SHjjES9tFYGWT3PM9O+fXShm3iLsEaBaWFTO\n\tKZbCyHuwvGT413UPeAsTfNWCZ+D6TKKBliWWIxMvhVbV1g2VBh1PcoJ217of3qRRObN5\n\tpigqGFotjpndUeI8TjsgkZtcc/4lG2io0vQj05R7kbXpc5tF3yKWuKLNtvdrw2DZOGU5\n\tdHbmMCf4L/S/xXQyJqKQpJwmkV84M6HwRxhy57BZ+mefSFgUzKChz5mBE9LbnYnuyM6T\n\tq1dO9Sw7pujgq47BgXdcXVwfcr8td/cc1hpJvIfl1UDVu/frneVEF6giLeU6rwe8mk+d\n\tY9Zw==","X-Gm-Message-State":"AIkVDXJ5aSeS6V6+Cgh6Qbmjb2JQmZ85hYybwAOOX1UkJdS7FnhQAtzArcMPXJA+orPPBQ==","X-Received":"by 10.25.208.20 with SMTP id h20mr514405lfg.150.1485934730205;\n\tTue, 31 Jan 2017 23:38:50 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"","Date":"Wed, 1 Feb 2017 08:38:48 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1571679,"web_url":"http://patchwork.ozlabs.org/comment/1571679/","msgid":"","list_archive_url":null,"date":"2017-02-01T15:56:07","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:\n>>> On 01/25/2017 10:03 AM, Rafał Miłecki wrote:\n>>>> On 21 January 2017 at 22:42, Jacek Anaszewski\n>>>> wrote:\n>>>>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>>>>>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>>>>>> wrote:\n>>>>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>>>>> From: Rafał Miłecki \n>>>>>>>>\n>>>>>>>> Some LEDs can be related to particular devices described in DT. This\n>>>>>>>> property allows specifying such relations. E.g. USB LED should\n>>>>>>>> usually\n>>>>>>>> be used to indicate some USB port(s) state.\n>>>>>>>>\n>>>>>>>> Signed-off-by: Rafał Miłecki \n>>>>>>>> ---\n>>>>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is\n>>>>>>>> more generic and\n>>>>>>>> allows specifying other devices as well.\n>>>>>>>>\n>>>>>>>> When bindings patch is related to some followup implementation,\n>>>>>>>> they usually go\n>>>>>>>> through the same tree.\n>>>>>>>>\n>>>>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds:\n>>>>>>>> Improve examples by\n>>>>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git\n>>>>>>>> . Is there any\n>>>>>>>> way to solve this dependency issue? Or should this patch wait\n>>>>>>>> until 3.11 is\n>>>>>>>> released?\n>>>>>>>> ---\n>>>>>>>> Documentation/devicetree/bindings/leds/common.txt | 16\n>>>>>>>> ++++++++++++++++\n>>>>>>>> 1 file changed, 16 insertions(+)\n>>>>>>>>\n>>>>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> index 24b656014089..17632a041196 100644\n>>>>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>>>>> - panic-indicator : This property specifies that the LED should\n>>>>>>>> be used,\n>>>>>>>> if at all possible, as a panic indicator.\n>>>>>>>>\n>>>>>>>> +- led-triggers : List of devices that should trigger this LED\n>>>>>>>> activity. Some\n>>>>>>>> + LEDs can be related to a specific device and\n>>>>>>>> should somehow\n>>>>>>>> + indicate its state. E.g. USB 2.0 LED may react to\n>>>>>>>> device(s) in\n>>>>>>>> + a USB 2.0 port(s). Another common example is\n>>>>>>>> switch or router\n>>>>>>>> + with multiple Ethernet ports each of them having\n>>>>>>>> its own LED\n>>>>>>>> + assigned (assuminled-trigger-usbportg they are not\n>>>>>>>> hardwired).\n>>>>>>>> + In such cases this property should contain\n>>>>>>>> phandle(s) of\n>>>>>>>> + related device(s). In many cases LED can be\n>>>>>>>> related to more\n>>>>>>>> + than one device (e.g. one USB LED vs. multiple USB\n>>>>>>>> ports) so a\n>>>>>>>> + list of entries can be specified.\n>>>>>>>> +\n>>>>>>>\n>>>>>>> This implies that it is possible to define multiple triggers for\n>>>>>>> a LED class device but it is not supported by LED Trigger core.\n>>>>>>> There is linux,default-trigger property which allows to define one\n>>>>>>> trigger that will be initially assigned.\n>>>>>\n>>>>>> With proposed \"led-triggers\" property one could assign different\n>>>>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network\n>>>>>> device & CPU to a single LED. For reason explained above Linux\n>>>>>> couldn't support all of them at once.\n>>>>>>\n>>>>>>\n>>>>>>> I am aware that this is renamed usb-ports property from v1,\n>>>>>>> that attempts to address Rob's comment, but we can't do that this\n>>>>>>> way.\n>>>>>>> Maybe usb-ports property could be documented in led-trigger-usbport's\n>>>>>>> specific bindings and a reference to it could be added next to the\n>>>>>>> related entry on the list of the available LED triggers (which is\n>>>>>>> actually missing) in\n>>>>>>> Documentation/devicetree/bindings/leds/common.txt.\n>>>>>>\n>>>>>> I'm wondering if we need to care about this Linux limitation and if it\n>>>>>> should stop us from adding this flexible DT property. Maybe we could\n>>>>>> live with Linux having limitation of supporting one trigger type at a\n>>>>>> time?\n>>>>>\n>>>>> That's what I meant. Generally I have objections to the generic\n>>>>> property for defining list of allowed triggers. That's why I proposed\n>>>>> to stay by usb-ports property that would be specific to only one\n>>>>> trigger: led-trigger-usbport.\n>>>>>\n>>>>> led-trigger-usbport in fact is an entirely new type of LED trigger.\n>>>>> LED triggers is a kernel based source of events. All existing triggers\n>>>>> react only to a single, well defined source of events, whereas\n>>>>> led-trigger-usbport allows to define the scope of events (usb ports)\n>>>>> to notify about. Activity on each port is treated similarly and the LED\n>>>>> class device that listens to the trigger notifications doesn't know\n>>>>> which exact port triggered the notification.\n>>>>>\n>>>>> From this POV led-trigger-usbport is kind of facade, which allows\n>>>>> for it to fit well into the LED Trigger design and API, and usb ports\n>>>>> are not identical with LED triggers, but sit rather one level below.\n>>>>> It is led-trigger-usbport which is visible to the LED subsystem, and\n>>>>> not every single usb port.\n>>>>>\n>>>>>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>>>>>> decides to use \"usport\" trigger driver he'll get LED indicating status\n>>>>>> of USB ports only.\n>>>>>\n>>>>> How would it be different from the current state? Only in limiting\n>>>>> the scope of triggers available for a LED class device.\n>>>>\n>>>> It won't differ from the current state. I just wanted to make it clear\n>>>> Linux trigger drivers may respect only selected \"led-triggers\" values\n>>>> (phandles). Like \"usbport\" respecting USB port phandles but ignoring\n>>>> CPU ones, net ones, etc.\n>>>\n>>> This is the ambiguity I want to avoid. According to my analysis from\n>>> the previous message, physical usb port is one level below usbport LED\n>>> trigger, and it should be reflected in DT binding documentation. You\n>>> can't write usb1-port1 (using the convention from Documentation/leds/\n>>> ledtrig-usbport.txt) to the \"triggers\" sysfs file. You can only register\n>>> usbport trigger which can be configured to notify about activity on\n>>> usb1-port1.\n>>>\n>>> That's why I proposed linux,trigger-sources name for that.\n>>> Let's not confuse LED triggers with events originating from physical\n>>> devices or other sources of kernel events, being in turn translated by\n>>> LED triggers to LED brightness changes.\n>>>\n>>> This is a thing about naming. It is tempting to call sources of kernel\n>>> events \"triggers\", but they are not LED triggers on they own. LED\n>>> trigger is a driver that registers itself in LED Trigger core using\n>>> led_trigger_register() API.\n>>\n>> Thanks a lot Jacek for this explanation (and sorry but I needed a bit of\n>> time to\n>> think about this). I can finally see your point, I think we're on the\n>> same page\n>> now.\n>>\n>> I think that for all this time I was thinking from the pure DT\n>> perspective. If\n>> you ignore fact that Linux has multiple LED trigger drivers, then\n>> \"led-triggers\"\n>> may not sound that bad.\n>>\n>> After reading your description however I can see this property can be\n>> misleading\n>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>\n>> I still think this is a useful property and I hope we can still find a\n>> way to\n>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>> subsystem.\n>\n> I also see the need for this property.\n>\n>> I think we should still work on some generic property (without linux,\n>> prefix) as\n>> this seems to be something generic, not really specific to Linux\n>> implementation.\n>> Specifying relation between LED and devices is something than AFAICS can be\n>> reused by other systems as well.\n>>\n>> So my suggestion is to try some new name & leave linux,default-trigger\n>> to allow\n>> specifying one single trigger driver as required by current Linux\n>> implementation.\n>>\n>> What do you think about this?\n>>\n>> There are few suggestions to came to my mind:\n>> \"trigger-sources\"\n>> \"trigger-devices\"\n>> \"led-trigger-devices\"\n>> \"led-related-devices\"\n>> \"led-event-devices\"\n>\n> trigger-devices would work in this specific use case,\n> where we can give phandles to usb ports. Nonetheless, we\n> have also other kernel based events serving as trigger\n> sources - e.g. timer.\n>\n> In this case I'd go for trigger-sources, but we'd need\n> to have some generic way of defining the source like timer.\n\nI'd leave timer for later discussion but I'm glad you brought this problem.\nMaybe we could discuss this on another example that is more supported like\nGPIOs?\n\nWe know this property allows specifying USB ports and we want it to support\nmixing various sources. So a very simple sample case seems to be using it for\nspecifying GPIO as trigger source.\n\nIs this possible to mix various entries in a list assigned to single property?\nLet's say:\ntrigger-sources =\n\t<&ohci_port1>,\n\t<&ehci_port1>,\n\t<&gpio 1 GPIO_ACTIVE_HIGH>;\n\nIs this possible to support this? If so, which function I can use to detect\nwhat is pointed by a phandle?\nI'm not that familiar with DT and I'm not sure how to handle this.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vD75q1GN6z9sDB\n\tfor ;\n\tThu, 2 Feb 2017 02:56:15 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750941AbdBAP4N (ORCPT\n\t);\n\tWed, 1 Feb 2017 10:56:13 -0500","from mail-lf0-f67.google.com ([209.85.215.67]:33092 \"EHLO\n\tmail-lf0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750863AbdBAP4M (ORCPT\n\t); Wed, 1 Feb 2017 10:56:12 -0500","by mail-lf0-f67.google.com with SMTP id x1so36880883lff.0;\n\tWed, 01 Feb 2017 07:56:11 -0800 (PST)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233])\n\tby smtp.googlemail.com with ESMTPSA id\n\tc2sm5824896ljb.24.2017.02.01.07.56.08\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 01 Feb 2017 07:56:09 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"Him9hKLj\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=aUU/O8eo/ayvi88/EMY+bw4Lcg7axwN3YQRise/LM/4=;\n\tb=Him9hKLjRamFInLupYQC/KI6Xh7juI4eoS9EevRQQIMdSbKoTAtPoWGbVT5npbZLTg\n\tHAUU3DuMfOYTc1KLwKXKoiwKN4LTWSOSakU3xLV6ojyHolkvR9qnB02kg1MhM5RlNi3w\n\tQzZ5WxNRS+1a1AfvksZG4gOu+U2Tc4deQASG7re+sDuzoNSdnQQ9m38JDvdswGF/bmE9\n\tqLgu0jmHxaiZfj41ELC5EvH7+wUUN2DNKQgLapRie/mZEldUUPkFabGZYbsAKjLkJFvu\n\tGMO0xAE360Px8SzhfvV0lq+/q9D7Y0a6jEKfiYVMrihLmkkKroE/nN10ZvRnHRnd+vDY\n\tlETw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=aUU/O8eo/ayvi88/EMY+bw4Lcg7axwN3YQRise/LM/4=;\n\tb=KFEfi3c460BEFvt8cQdj0aTvqOBYrF0N5YNf0NJBB+RejAcFTAASOoDAG3yFN/mxrg\n\tYkKOs8xzT1QwWnzZpGPQRkf3J80R8boVrjMAKzStDun2FkbN0XXb1NB8RCSux5hQzmVU\n\t1bXb9EAK6aaeC2hCyH9WK26TzOk6Sx1zfEOV3Z0e7YKrH9ZzFdlEn8GxS2rr78Q36CGC\n\tN8kAiCGogLKLecYWPDjQPXaJfV1MU3ESju+UJmjLmBRUYAxIK0VTbQv3mzZ0PctfN6/2\n\tjNe4ZhTxisKlJVsqX4ltSwSswsgeOLSL4OoXMPQy7PSiMGjzD00GvgbDXQMX79ZsFhdd\n\tLxiw==","X-Gm-Message-State":"AIkVDXI9Wo8/WXZGZq/b8+dOlfFfwewKVjx1LbIGssTra1YToPldF1Ba0cUeg6BbEhwHmQ==","X-Received":"by 10.25.34.196 with SMTP id i187mr1382020lfi.176.1485964569906; \n\tWed, 01 Feb 2017 07:56:09 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ,\n\t=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"","Date":"Wed, 1 Feb 2017 16:56:07 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1571995,"web_url":"http://patchwork.ozlabs.org/comment/1571995/","msgid":"<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>","list_archive_url":null,"date":"2017-02-01T21:26:55","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 02/01/2017 04:56 PM, Rafał Miłecki wrote:\n> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>>> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:\n>>>> On 01/25/2017 10:03 AM, Rafał Miłecki wrote:\n>>>>> On 21 January 2017 at 22:42, Jacek Anaszewski\n>>>>> wrote:\n>>>>>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:\n>>>>>>> On 20 January 2017 at 23:35, Jacek Anaszewski\n>>>>>>> wrote:\n>>>>>>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:\n>>>>>>>>> From: Rafał Miłecki \n>>>>>>>>>\n>>>>>>>>> Some LEDs can be related to particular devices described in DT.\n>>>>>>>>> This\n>>>>>>>>> property allows specifying such relations. E.g. USB LED should\n>>>>>>>>> usually\n>>>>>>>>> be used to indicate some USB port(s) state.\n>>>>>>>>>\n>>>>>>>>> Signed-off-by: Rafał Miłecki \n>>>>>>>>> ---\n>>>>>>>>> V2: Replace \"usb-ports\" with \"led-triggers\" property which is\n>>>>>>>>> more generic and\n>>>>>>>>> allows specifying other devices as well.\n>>>>>>>>>\n>>>>>>>>> When bindings patch is related to some followup implementation,\n>>>>>>>>> they usually go\n>>>>>>>>> through the same tree.\n>>>>>>>>>\n>>>>>>>>> Greg: this patch is based on top of e64b8cc72bf9 (\"DT: leds:\n>>>>>>>>> Improve examples by\n>>>>>>>>> adding some context\") from kernel/git/j.anaszewski/linux-leds.git\n>>>>>>>>> . Is there any\n>>>>>>>>> way to solve this dependency issue? Or should this patch wait\n>>>>>>>>> until 3.11 is\n>>>>>>>>> released?\n>>>>>>>>> ---\n>>>>>>>>> Documentation/devicetree/bindings/leds/common.txt | 16\n>>>>>>>>> ++++++++++++++++\n>>>>>>>>> 1 file changed, 16 insertions(+)\n>>>>>>>>>\n>>>>>>>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>>> b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>>> index 24b656014089..17632a041196 100644\n>>>>>>>>> --- a/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>>> +++ b/Documentation/devicetree/bindings/leds/common.txt\n>>>>>>>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:\n>>>>>>>>> - panic-indicator : This property specifies that the LED should\n>>>>>>>>> be used,\n>>>>>>>>> if at all possible, as a panic indicator.\n>>>>>>>>>\n>>>>>>>>> +- led-triggers : List of devices that should trigger this LED\n>>>>>>>>> activity. Some\n>>>>>>>>> + LEDs can be related to a specific device and\n>>>>>>>>> should somehow\n>>>>>>>>> + indicate its state. E.g. USB 2.0 LED may react to\n>>>>>>>>> device(s) in\n>>>>>>>>> + a USB 2.0 port(s). Another common example is\n>>>>>>>>> switch or router\n>>>>>>>>> + with multiple Ethernet ports each of them having\n>>>>>>>>> its own LED\n>>>>>>>>> + assigned (assuminled-trigger-usbportg they are not\n>>>>>>>>> hardwired).\n>>>>>>>>> + In such cases this property should contain\n>>>>>>>>> phandle(s) of\n>>>>>>>>> + related device(s). In many cases LED can be\n>>>>>>>>> related to more\n>>>>>>>>> + than one device (e.g. one USB LED vs. multiple USB\n>>>>>>>>> ports) so a\n>>>>>>>>> + list of entries can be specified.\n>>>>>>>>> +\n>>>>>>>>\n>>>>>>>> This implies that it is possible to define multiple triggers for\n>>>>>>>> a LED class device but it is not supported by LED Trigger core.\n>>>>>>>> There is linux,default-trigger property which allows to define one\n>>>>>>>> trigger that will be initially assigned.\n>>>>>>\n>>>>>>> With proposed \"led-triggers\" property one could assign different\n>>>>>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports,\n>>>>>>> network\n>>>>>>> device & CPU to a single LED. For reason explained above Linux\n>>>>>>> couldn't support all of them at once.\n>>>>>>>\n>>>>>>>\n>>>>>>>> I am aware that this is renamed usb-ports property from v1,\n>>>>>>>> that attempts to address Rob's comment, but we can't do that this\n>>>>>>>> way.\n>>>>>>>> Maybe usb-ports property could be documented in\n>>>>>>>> led-trigger-usbport's\n>>>>>>>> specific bindings and a reference to it could be added next to the\n>>>>>>>> related entry on the list of the available LED triggers (which is\n>>>>>>>> actually missing) in\n>>>>>>>> Documentation/devicetree/bindings/leds/common.txt.\n>>>>>>>\n>>>>>>> I'm wondering if we need to care about this Linux limitation and\n>>>>>>> if it\n>>>>>>> should stop us from adding this flexible DT property. Maybe we could\n>>>>>>> live with Linux having limitation of supporting one trigger type\n>>>>>>> at a\n>>>>>>> time?\n>>>>>>\n>>>>>> That's what I meant. Generally I have objections to the generic\n>>>>>> property for defining list of allowed triggers. That's why I proposed\n>>>>>> to stay by usb-ports property that would be specific to only one\n>>>>>> trigger: led-trigger-usbport.\n>>>>>>\n>>>>>> led-trigger-usbport in fact is an entirely new type of LED trigger.\n>>>>>> LED triggers is a kernel based source of events. All existing\n>>>>>> triggers\n>>>>>> react only to a single, well defined source of events, whereas\n>>>>>> led-trigger-usbport allows to define the scope of events (usb ports)\n>>>>>> to notify about. Activity on each port is treated similarly and\n>>>>>> the LED\n>>>>>> class device that listens to the trigger notifications doesn't know\n>>>>>> which exact port triggered the notification.\n>>>>>>\n>>>>>> From this POV led-trigger-usbport is kind of facade, which allows\n>>>>>> for it to fit well into the LED Trigger design and API, and usb ports\n>>>>>> are not identical with LED triggers, but sit rather one level below.\n>>>>>> It is led-trigger-usbport which is visible to the LED subsystem, and\n>>>>>> not every single usb port.\n>>>>>>\n>>>>>>> So e.g. if one assigns 2 USB ports + network device + CPU and\n>>>>>>> decides to use \"usport\" trigger driver he'll get LED indicating\n>>>>>>> status\n>>>>>>> of USB ports only.\n>>>>>>\n>>>>>> How would it be different from the current state? Only in limiting\n>>>>>> the scope of triggers available for a LED class device.\n>>>>>\n>>>>> It won't differ from the current state. I just wanted to make it clear\n>>>>> Linux trigger drivers may respect only selected \"led-triggers\" values\n>>>>> (phandles). Like \"usbport\" respecting USB port phandles but ignoring\n>>>>> CPU ones, net ones, etc.\n>>>>\n>>>> This is the ambiguity I want to avoid. According to my analysis from\n>>>> the previous message, physical usb port is one level below usbport LED\n>>>> trigger, and it should be reflected in DT binding documentation. You\n>>>> can't write usb1-port1 (using the convention from Documentation/leds/\n>>>> ledtrig-usbport.txt) to the \"triggers\" sysfs file. You can only\n>>>> register\n>>>> usbport trigger which can be configured to notify about activity on\n>>>> usb1-port1.\n>>>>\n>>>> That's why I proposed linux,trigger-sources name for that.\n>>>> Let's not confuse LED triggers with events originating from physical\n>>>> devices or other sources of kernel events, being in turn translated by\n>>>> LED triggers to LED brightness changes.\n>>>>\n>>>> This is a thing about naming. It is tempting to call sources of kernel\n>>>> events \"triggers\", but they are not LED triggers on they own. LED\n>>>> trigger is a driver that registers itself in LED Trigger core using\n>>>> led_trigger_register() API.\n>>>\n>>> Thanks a lot Jacek for this explanation (and sorry but I needed a bit of\n>>> time to\n>>> think about this). I can finally see your point, I think we're on the\n>>> same page\n>>> now.\n>>>\n>>> I think that for all this time I was thinking from the pure DT\n>>> perspective. If\n>>> you ignore fact that Linux has multiple LED trigger drivers, then\n>>> \"led-triggers\"\n>>> may not sound that bad.\n>>>\n>>> After reading your description however I can see this property can be\n>>> misleading\n>>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>>\n>>> I still think this is a useful property and I hope we can still find a\n>>> way to\n>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>>> subsystem.\n>>\n>> I also see the need for this property.\n>>\n>>> I think we should still work on some generic property (without linux,\n>>> prefix) as\n>>> this seems to be something generic, not really specific to Linux\n>>> implementation.\n>>> Specifying relation between LED and devices is something than AFAICS\n>>> can be\n>>> reused by other systems as well.\n>>>\n>>> So my suggestion is to try some new name & leave linux,default-trigger\n>>> to allow\n>>> specifying one single trigger driver as required by current Linux\n>>> implementation.\n>>>\n>>> What do you think about this?\n>>>\n>>> There are few suggestions to came to my mind:\n>>> \"trigger-sources\"\n>>> \"trigger-devices\"\n>>> \"led-trigger-devices\"\n>>> \"led-related-devices\"\n>>> \"led-event-devices\"\n>>\n>> trigger-devices would work in this specific use case,\n>> where we can give phandles to usb ports. Nonetheless, we\n>> have also other kernel based events serving as trigger\n>> sources - e.g. timer.\n>>\n>> In this case I'd go for trigger-sources, but we'd need\n>> to have some generic way of defining the source like timer.\n> \n> I'd leave timer for later discussion but I'm glad you brought this problem.\n> Maybe we could discuss this on another example that is more supported like\n> GPIOs?\n> \n> We know this property allows specifying USB ports and we want it to support\n> mixing various sources. So a very simple sample case seems to be using\n> it for\n> specifying GPIO as trigger source.\n> \n> Is this possible to mix various entries in a list assigned to single\n> property?\n> Let's say:\n> trigger-sources =\n> <&ohci_port1>,\n> <&ehci_port1>,\n> <&gpio 1 GPIO_ACTIVE_HIGH>;\n\nAccording to my knowledge all elements in the list are elements\nof one array, no matter if they are comma separated or space separated\nin \"<>\" brackets. DT maintainer would have to confirm that though.\n\n> Is this possible to support this? If so, which function I can use to detect\n> what is pointed by a phandle?\n> I'm not that familiar with DT and I'm not sure how to handle this.\n\nI wonder if this is correct way to go. Maybe we should think of\ncreating entirely new trigger mechanism that would allow for having\nmultiple active triggers at a time.\n\nOf course trigger-sources would be still useful for defining\na list of devices of the same type like in case of usbport trigger.\nNonetheless, I have a problem with this property being a part of\nLED class device DT bindings. Triggers are not tightly coupled with\nLED class devices, but trigger-sources being a list of usb ports\nwould be applicable only to usbport trigger. What if there was\nanother combo trigger e.g. for reporting activity on mulitple GPIOs?\n\nShould we have separate list of trigger sources per any possible\nexisting trigger type? Aren't we going to far from pure hardware\ndescription the Device Tree was initially predestined to?","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vDGSP4swWz9sQw\n\tfor ;\n\tThu, 2 Feb 2017 08:27:49 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751240AbdBAV1q (ORCPT\n\t);\n\tWed, 1 Feb 2017 16:27:46 -0500","from mail-wm0-f68.google.com ([74.125.82.68]:35830 \"EHLO\n\tmail-wm0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751232AbdBAV1p (ORCPT\n\t); Wed, 1 Feb 2017 16:27:45 -0500","by mail-wm0-f68.google.com with SMTP id u63so8409585wmu.2;\n\tWed, 01 Feb 2017 13:27:44 -0800 (PST)","from [192.168.1.17] (dnn201.neoplus.adsl.tpnet.pl. [83.24.95.201])\n\tby smtp.gmail.com with ESMTPSA id\n\tb15sm36086755wra.4.2017.02.01.13.27.41\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 01 Feb 2017 13:27:42 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"APlZW4JL\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=hZR1VeNXWcP+6MPdr7k8WAm2taP9bXoOZ6uDDdOnF7c=;\n\tb=APlZW4JLanallunGmlRlgy28Q35XlbigV/8Tao8F40n1odMcGMJLB5S87nAogTBia/\n\tQy+meVdNPT7GQxHcmt78STLZ95y0n1SOrbC6poF0rmnQyd7ZGwYaloY5q2FCuVOYENQW\n\tgzPkdQCQbHAVclVlZiCUgjqDJR90fse+xoc3/nKNcvYvpkVHaoHJ8oU675zpMFwfaosD\n\tSRu0MNWSqUdj0D9zlLZmZjfd2dHZ64nyX6YNYPO90rmRv/ZTBa0asuI+uTJXFxYO0R9C\n\tzDqhzox2ilDEyL0bn1tq4eKWAn03WZSNiU48CH6E5uNlBERd/Oj5twRSKQMcCKwCka3b\n\tYjaw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=hZR1VeNXWcP+6MPdr7k8WAm2taP9bXoOZ6uDDdOnF7c=;\n\tb=AZr/TxSD47pVLP4AzP/AK3qphLPK1VQKGzrbwA6YYjp/HG2dGRg8lPJ97K5d270sZj\n\tACmBuok7NluTSkS/Lz05C+HePMDsS0BDIqC2NuiyiB6yWTvLmGRByl4Znzh7XbrftjkI\n\tUdhsjxDszC0exIj0kQqSzWJ3MvBZhRNk7me5S8hKAAILUWAGjjm5xjmWzLhYMUUTAeg0\n\tixd5YiX65uEkf/M3Aj93IzOjbqbQ8PgIx6i4H8mnx14AaFz07nw6bX+Cie1/UN+YpS0I\n\tcKyLeNXT4zo4P6+zUyPSycR3/89WFUC/hi3nVce/yjuqMnfEhLCs0tZHGKEXGodO3gNV\n\t+prw==","X-Gm-Message-State":"AIkVDXI+NlZcAxfeA2O1qVcLuGGDqynNcZJj0uz9T/YY48zJMpjyih2yTAR7/tIGUTd9wQ==","X-Received":"by 10.223.164.150 with SMTP id g22mr4435550wrb.148.1485984463011;\n\tWed, 01 Feb 2017 13:27:43 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tRob Herring , Mark Rutland ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>","Date":"Wed, 1 Feb 2017 22:26:55 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1572012,"web_url":"http://patchwork.ozlabs.org/comment/1572012/","msgid":"<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>","list_archive_url":null,"date":"2017-02-01T21:55:15","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:\n> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:\n>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>>>> Thanks a lot Jacek for this explanation (and sorry but I needed a bit of\n>>>> time to\n>>>> think about this). I can finally see your point, I think we're on the\n>>>> same page\n>>>> now.\n>>>>\n>>>> I think that for all this time I was thinking from the pure DT\n>>>> perspective. If\n>>>> you ignore fact that Linux has multiple LED trigger drivers, then\n>>>> \"led-triggers\"\n>>>> may not sound that bad.\n>>>>\n>>>> After reading your description however I can see this property can be\n>>>> misleading\n>>>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>>>\n>>>> I still think this is a useful property and I hope we can still find a\n>>>> way to\n>>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>>>> subsystem.\n>>>\n>>> I also see the need for this property.\n>>>\n>>>> I think we should still work on some generic property (without linux,\n>>>> prefix) as\n>>>> this seems to be something generic, not really specific to Linux\n>>>> implementation.\n>>>> Specifying relation between LED and devices is something than AFAICS\n>>>> can be\n>>>> reused by other systems as well.\n>>>>\n>>>> So my suggestion is to try some new name & leave linux,default-trigger\n>>>> to allow\n>>>> specifying one single trigger driver as required by current Linux\n>>>> implementation.\n>>>>\n>>>> What do you think about this?\n>>>>\n>>>> There are few suggestions to came to my mind:\n>>>> \"trigger-sources\"\n>>>> \"trigger-devices\"\n>>>> \"led-trigger-devices\"\n>>>> \"led-related-devices\"\n>>>> \"led-event-devices\"\n>>>\n>>> trigger-devices would work in this specific use case,\n>>> where we can give phandles to usb ports. Nonetheless, we\n>>> have also other kernel based events serving as trigger\n>>> sources - e.g. timer.\n>>>\n>>> In this case I'd go for trigger-sources, but we'd need\n>>> to have some generic way of defining the source like timer.\n>>\n>> I'd leave timer for later discussion but I'm glad you brought this problem.\n>> Maybe we could discuss this on another example that is more supported like\n>> GPIOs?\n>>\n>> We know this property allows specifying USB ports and we want it to support\n>> mixing various sources. So a very simple sample case seems to be using\n>> it for\n>> specifying GPIO as trigger source.\n>>\n>> Is this possible to mix various entries in a list assigned to single\n>> property?\n>> Let's say:\n>> trigger-sources =\n>> <&ohci_port1>,\n>> <&ehci_port1>,\n>> <&gpio 1 GPIO_ACTIVE_HIGH>;\n>\n> According to my knowledge all elements in the list are elements\n> of one array, no matter if they are comma separated or space separated\n> in \"<>\" brackets. DT maintainer would have to confirm that though.\n\nThis matches my knowledge as well.\n\n\n>> Is this possible to support this? If so, which function I can use to detect\n>> what is pointed by a phandle?\n>> I'm not that familiar with DT and I'm not sure how to handle this.\n>\n> I wonder if this is correct way to go. Maybe we should think of\n> creating entirely new trigger mechanism that would allow for having\n> multiple active triggers at a time.\n\nI'm OK with reworking Linux's triggers if it need be. I think we should agree\non binding(s) first though.\n\n\n> Of course trigger-sources would be still useful for defining\n> a list of devices of the same type like in case of usbport trigger.\n> Nonetheless, I have a problem with this property being a part of\n> LED class device DT bindings. Triggers are not tightly coupled with\n> LED class devices, but trigger-sources being a list of usb ports\n> would be applicable only to usbport trigger. What if there was\n> another combo trigger e.g. for reporting activity on mulitple GPIOs?\n\nThat was exactly my point with above trigger-sources example including 2 USB\nports & GPIO.\n\n\n> Should we have separate list of trigger sources per any possible\n> existing trigger type? Aren't we going to far from pure hardware\n> description the Device Tree was initially predestined to?\n\nThat would simplify things, but it gets us back to *multiple* properties like\nled-usb-triggers (or led-usb-trigger-sources)\nled-pci-triggers (or led-pci-trigger-sources)\nled-gpio-triggers (or led-gpio-trigger-sources)\netc.\n\nLast time Rob said he's not going to accept something like this, see:\n\nOn 23 January 2017 at 17:45, Rob Herring wrote:\n > I'm not going to accept something specific to USB. So the choice is make\n > the existing property work for USB or design something more flexible and\n > generic.\n\nSo I think the main question right now is if this is possible to support mixed\nentries in a list like that\ntrigger-sources =\n\t<&ohci_port1>,\n\t<&ehci_port1>,\n\t<&gpio 1 GPIO_ACTIVE_HIGH>;\n\nI posted as example.\n\nI was also trying to find help on IRC #devicetree channel but didn't get any\nresponse:\n[09:15] hi, i've a question about mixing various entries in a single list\n[09:16] is this possible to have different /syntax/ in every list element\n[09:16] and have driver detect what does it reference?\n[09:16] i'll post an example\n[09:17] trigger-sources = <&ohci_port1>, <&ehci_port1>, <&gpio 1 GPIO_ACTIVE_HIGH>;\n[09:18] this question is related to my work in [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property\n[09:18] beware, there is a long discussion in that thread\n\nRob: do you still follow this thread? We'd like to use single property as you\nsuggested, but is it possible to work with something like trigger-sources\nexample posted above?\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vDH4G11x8z9s9Y\n\tfor ;\n\tThu, 2 Feb 2017 08:55:25 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752175AbdBAVzY (ORCPT\n\t);\n\tWed, 1 Feb 2017 16:55:24 -0500","from mail-lf0-f67.google.com ([209.85.215.67]:34405 \"EHLO\n\tmail-lf0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751832AbdBAVzX (ORCPT\n\t); Wed, 1 Feb 2017 16:55:23 -0500","by mail-lf0-f67.google.com with SMTP id q89so37483520lfi.1;\n\tWed, 01 Feb 2017 13:55:21 -0800 (PST)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233])\n\tby smtp.googlemail.com with ESMTPSA id\n\tm18sm6019274lfe.45.2017.02.01.13.55.19\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 01 Feb 2017 13:55:19 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"H26iFX5e\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=zArChqiNHplGP0eHGJKtueQStvb45++KD3TGHvuwAjQ=;\n\tb=H26iFX5eB5+tZo7XO8U5QEo63UNC2/UVAIBhofsiHH+t7xC+Rs4lthOU6TU6Hg6izd\n\tTaKgZpZGhh7zG6QSknSsIgJaoIvrWkjGJzd1UFODhjhIzgyRPEr0Qx0O5fO38w8IUgtc\n\tKeGbaOgCPTNULncYpRKxghd9tg1GpX25tyR2HFv0vNKGbrf/BTU13s76idsy1DloO49Q\n\tZmZVXZDgwyKgm6l6uJPeYfmTuEdUH+dqcoJI6eVUvbI4dcSC1OMDmOf2Tc7zoMPYhzje\n\tOqDfBNJuwEWcNBLFmpEe3In495ouW0gRUnH6gyqtsQ5LbX5deDZTfdvBHMcEGbKkOqZa\n\tW4Eg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=zArChqiNHplGP0eHGJKtueQStvb45++KD3TGHvuwAjQ=;\n\tb=c9gjCEnf9n5Qnlm0/2ZxShEwb32ZPJP8juEp+1OaC9gGP91rf09dl4/krit//aPt8r\n\tLU2OOJz6L1UonfeLgzCfjF2FVp8XAbinOUENKTJgPuDvYF7kG0a/6FDYrJ6WvKWh/WcO\n\tPPzT7wr1rR5AxfhG35vKiiXPFKb9CJoxvogzjnPil3QdBobyKCbxbxY186fQOzjmdap6\n\tQGZUbQoLN7RQ+4jcQeUcs++0enOiUqN6ZZDDzj/MZKOBIa5Q8Kdvzm+zZqDqBVAdydcI\n\tlceqjlUE0uHGpy6EaSZChkV7w6V+W786gHXxfUwiUGKX4xQXoq3QPDPzajRPKXINBMHZ\n\thQmw==","X-Gm-Message-State":"AIkVDXL2h/Z3MAv4bigUTK1eqcKi/g0bz9SIyzgbCqnThvm7+iuVSs1g3k+DFXnHsOXhhQ==","X-Received":"by 10.46.77.9 with SMTP id a9mr2280179ljb.25.1485986120543;\n\tWed, 01 Feb 2017 13:55:20 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t\n\t<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tMark Rutland ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>","Date":"Wed, 1 Feb 2017 22:55:15 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1573166,"web_url":"http://patchwork.ozlabs.org/comment/1573166/","msgid":"","list_archive_url":null,"date":"2017-02-02T20:44:12","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 02/01/2017 10:55 PM, Rafał Miłecki wrote:\n> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:\n>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:\n>>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n>>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>>>>> Thanks a lot Jacek for this explanation (and sorry but I needed a\n>>>>> bit of\n>>>>> time to\n>>>>> think about this). I can finally see your point, I think we're on the\n>>>>> same page\n>>>>> now.\n>>>>>\n>>>>> I think that for all this time I was thinking from the pure DT\n>>>>> perspective. If\n>>>>> you ignore fact that Linux has multiple LED trigger drivers, then\n>>>>> \"led-triggers\"\n>>>>> may not sound that bad.\n>>>>>\n>>>>> After reading your description however I can see this property can be\n>>>>> misleading\n>>>>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>>>>\n>>>>> I still think this is a useful property and I hope we can still find a\n>>>>> way to\n>>>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>>>>> subsystem.\n>>>>\n>>>> I also see the need for this property.\n>>>>\n>>>>> I think we should still work on some generic property (without linux,\n>>>>> prefix) as\n>>>>> this seems to be something generic, not really specific to Linux\n>>>>> implementation.\n>>>>> Specifying relation between LED and devices is something than AFAICS\n>>>>> can be\n>>>>> reused by other systems as well.\n>>>>>\n>>>>> So my suggestion is to try some new name & leave linux,default-trigger\n>>>>> to allow\n>>>>> specifying one single trigger driver as required by current Linux\n>>>>> implementation.\n>>>>>\n>>>>> What do you think about this?\n>>>>>\n>>>>> There are few suggestions to came to my mind:\n>>>>> \"trigger-sources\"\n>>>>> \"trigger-devices\"\n>>>>> \"led-trigger-devices\"\n>>>>> \"led-related-devices\"\n>>>>> \"led-event-devices\"\n>>>>\n>>>> trigger-devices would work in this specific use case,\n>>>> where we can give phandles to usb ports. Nonetheless, we\n>>>> have also other kernel based events serving as trigger\n>>>> sources - e.g. timer.\n>>>>\n>>>> In this case I'd go for trigger-sources, but we'd need\n>>>> to have some generic way of defining the source like timer.\n>>>\n>>> I'd leave timer for later discussion but I'm glad you brought this\n>>> problem.\n>>> Maybe we could discuss this on another example that is more supported\n>>> like\n>>> GPIOs?\n>>>\n>>> We know this property allows specifying USB ports and we want it to\n>>> support\n>>> mixing various sources. So a very simple sample case seems to be using\n>>> it for\n>>> specifying GPIO as trigger source.\n>>>\n>>> Is this possible to mix various entries in a list assigned to single\n>>> property?\n>>> Let's say:\n>>> trigger-sources =\n>>> <&ohci_port1>,\n>>> <&ehci_port1>,\n>>> <&gpio 1 GPIO_ACTIVE_HIGH>;\n>>\n>> According to my knowledge all elements in the list are elements\n>> of one array, no matter if they are comma separated or space separated\n>> in \"<>\" brackets. DT maintainer would have to confirm that though.\n> \n> This matches my knowledge as well.\n\nHaving that, we would be limited to a list of fixed size\ntuples IMHO.\n\n> \n>>> Is this possible to support this? If so, which function I can use to\n>>> detect\n>>> what is pointed by a phandle?\n>>> I'm not that familiar with DT and I'm not sure how to handle this.\n>>\n>> I wonder if this is correct way to go. Maybe we should think of\n>> creating entirely new trigger mechanism that would allow for having\n>> multiple active triggers at a time.\n> \n> I'm OK with reworking Linux's triggers if it need be. I think we should\n> agree\n> on binding(s) first though.\n\nI was thinking of creating entirely new mechanism (new sysfs file),\nas we can't break existing users.\n\n\n> \n>> Of course trigger-sources would be still useful for defining\n>> a list of devices of the same type like in case of usbport trigger.\n>> Nonetheless, I have a problem with this property being a part of\n>> LED class device DT bindings. Triggers are not tightly coupled with\n>> LED class devices, but trigger-sources being a list of usb ports\n>> would be applicable only to usbport trigger. What if there was\n>> another combo trigger e.g. for reporting activity on mulitple GPIOs?\n> \n> That was exactly my point with above trigger-sources example including 2\n> USB\n> ports & GPIO.\n\nHow usbport trigger would make use use of information about GPIO?\nDoes it mean that in this approach triggers would arbitrarily choose\ntrigger-sources applicable for them?\n\n> \n>> Should we have separate list of trigger sources per any possible\n>> existing trigger type? Aren't we going to far from pure hardware\n>> description the Device Tree was initially predestined to?\n> \n> That would simplify things, but it gets us back to *multiple* properties\n> like\n> led-usb-triggers (or led-usb-trigger-sources)\n> led-pci-triggers (or led-pci-trigger-sources)\n> led-gpio-triggers (or led-gpio-trigger-sources)\n> etc.\n\nRight, I was rather skeptical in my question - I don't like this\nsolution too.\n\n> Last time Rob said he's not going to accept something like this, see:\n> \n> On 23 January 2017 at 17:45, Rob Herring wrote:\n>> I'm not going to accept something specific to USB. So the choice is make\n>> the existing property work for USB or design something more flexible and\n>> generic.\n> \n> So I think the main question right now is if this is possible to support\n> mixed\n> entries in a list like that\n> trigger-sources =\n> <&ohci_port1>,\n> <&ehci_port1>,\n> <&gpio 1 GPIO_ACTIVE_HIGH>;\n> \n> I posted as example.\n> \n> I was also trying to find help on IRC #devicetree channel but didn't get\n> any\n> response:\n> [09:15] hi, i've a question about mixing various entries in a\n> single list\n> [09:16] is this possible to have different /syntax/ in every\n> list element\n> [09:16] and have driver detect what does it reference?\n> [09:16] i'll post an example\n> [09:17] trigger-sources = <&ohci_port1>, <&ehci_port1>,\n> <&gpio 1 GPIO_ACTIVE_HIGH>;\n> [09:18] this question is related to my work in [PATCH V2 1/2]\n> dt-bindings: leds: document new led-triggers property\n> [09:18] beware, there is a long discussion in that thread\n> \n> Rob: do you still follow this thread? We'd like to use single property\n> as you\n> suggested, but is it possible to work with something like trigger-sources\n> example posted above?\n>","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vDsSd54t6z9s6s\n\tfor ;\n\tFri, 3 Feb 2017 07:45:05 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751817AbdBBUpE (ORCPT\n\t);\n\tThu, 2 Feb 2017 15:45:04 -0500","from mail-wm0-f67.google.com ([74.125.82.67]:34109 \"EHLO\n\tmail-wm0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751815AbdBBUpC (ORCPT\n\t); Thu, 2 Feb 2017 15:45:02 -0500","by mail-wm0-f67.google.com with SMTP id c85so697464wmi.1;\n\tThu, 02 Feb 2017 12:45:01 -0800 (PST)","from [192.168.1.17] (afqp186.neoplus.adsl.tpnet.pl.\n\t[178.42.171.186]) by smtp.gmail.com with ESMTPSA id\n\t202sm4985015wmp.20.2017.02.02.12.44.58\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 02 Feb 2017 12:44:59 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"tgE3Kzoo\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=LEAM1knFJd9BShgwnkKTGqykg73j72APvoRUcVaPt04=;\n\tb=tgE3KzooydaE8Otr7rKUMaZyYjuXvY9zw0AV7jJRX9dTIL9cR4DYMqjgYSQqy9kcAQ\n\tJhUaWjNzckm2AeyAdWSu0q6C/gS0vXCLUrFXEbszAhWYkauQ2SLel2HCBcv+liTuZgX1\n\tCG8NhxkkOkrLlRBXXfgKm1r07JoA5o1C1pC4PNR/bZ6LJYUctACgsPrOF+yVU0OC/+Ak\n\tHZw6X/hiOnVpo6W/u6+NG8Du2lvpxqvth8yMkNJZA36ojDQ6GDGGoQ8cuHlOa2qsGvbH\n\tKhNsurwu6TJj1vEbojWQMNYX18Ss5wTcVmQ1u4xf2AVaw9gJ+cjywxno79cu69Ahl0E5\n\tJomQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=LEAM1knFJd9BShgwnkKTGqykg73j72APvoRUcVaPt04=;\n\tb=kxOYZs/X9TfTdytqZNyNv0O2khuBPQV/vWmBf11HSI72w8EfbUDjZDTO+UEFNRyh5H\n\tXxRPVRlbPDzV27eEebuLBnScwoyrkfjxJTDxoEDdXNx9AgDH+MsUj7BkOXY9mrredeNS\n\thonV04XKW52DwzQFVMSW3Ed6ZqwNvGxCl/e+zJeTD2DvdwXA8ARfXxuJSPuLRN2QTQTf\n\tjDaHXod0KzKqw9TQtJKx+9NvKCbxEUJ04atJ2hDM/UeR2Zrr83Frjg4rFSepprYcFV+6\n\t7veCiOcLLgD5dWm1wbvvlXV+NadXX2Sk8JnxQ5XKDFQ9i33XH1v9Ft+jLshhnXZ+H84g\n\toaug==","X-Gm-Message-State":"AIkVDXLspwL+drcafYoqDlmhsmC/v0M6FNb67l3bi5imlHR+wUGqyVN4x39sVOYOyZtfTQ==","X-Received":"by 10.223.134.173 with SMTP id 42mr10861816wrx.95.1486068300234; \n\tThu, 02 Feb 2017 12:45:00 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t\n\t<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>\n\t<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tMark Rutland ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"","Date":"Thu, 2 Feb 2017 21:44:12 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1573234,"web_url":"http://patchwork.ozlabs.org/comment/1573234/","msgid":"","list_archive_url":null,"date":"2017-02-02T23:00:46","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":5824,"url":"http://patchwork.ozlabs.org/api/people/5824/","name":"Rafał Miłecki","email":"zajec5@gmail.com"},"content":"On 02/02/2017 09:44 PM, Jacek Anaszewski wrote:\n> On 02/01/2017 10:55 PM, Rafał Miłecki wrote:\n>> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:\n>>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:\n>>>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n>>>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>>>>>> Thanks a lot Jacek for this explanation (and sorry but I needed a\n>>>>>> bit of\n>>>>>> time to\n>>>>>> think about this). I can finally see your point, I think we're on the\n>>>>>> same page\n>>>>>> now.\n>>>>>>\n>>>>>> I think that for all this time I was thinking from the pure DT\n>>>>>> perspective. If\n>>>>>> you ignore fact that Linux has multiple LED trigger drivers, then\n>>>>>> \"led-triggers\"\n>>>>>> may not sound that bad.\n>>>>>>\n>>>>>> After reading your description however I can see this property can be\n>>>>>> misleading\n>>>>>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>>>>>\n>>>>>> I still think this is a useful property and I hope we can still find a\n>>>>>> way to\n>>>>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>>>>>> subsystem.\n>>>>>\n>>>>> I also see the need for this property.\n>>>>>\n>>>>>> I think we should still work on some generic property (without linux,\n>>>>>> prefix) as\n>>>>>> this seems to be something generic, not really specific to Linux\n>>>>>> implementation.\n>>>>>> Specifying relation between LED and devices is something than AFAICS\n>>>>>> can be\n>>>>>> reused by other systems as well.\n>>>>>>\n>>>>>> So my suggestion is to try some new name & leave linux,default-trigger\n>>>>>> to allow\n>>>>>> specifying one single trigger driver as required by current Linux\n>>>>>> implementation.\n>>>>>>\n>>>>>> What do you think about this?\n>>>>>>\n>>>>>> There are few suggestions to came to my mind:\n>>>>>> \"trigger-sources\"\n>>>>>> \"trigger-devices\"\n>>>>>> \"led-trigger-devices\"\n>>>>>> \"led-related-devices\"\n>>>>>> \"led-event-devices\"\n>>>>>\n>>>>> trigger-devices would work in this specific use case,\n>>>>> where we can give phandles to usb ports. Nonetheless, we\n>>>>> have also other kernel based events serving as trigger\n>>>>> sources - e.g. timer.\n>>>>>\n>>>>> In this case I'd go for trigger-sources, but we'd need\n>>>>> to have some generic way of defining the source like timer.\n>>>>\n>>>> I'd leave timer for later discussion but I'm glad you brought this\n>>>> problem.\n>>>> Maybe we could discuss this on another example that is more supported\n>>>> like\n>>>> GPIOs?\n>>>>\n>>>> We know this property allows specifying USB ports and we want it to\n>>>> support\n>>>> mixing various sources. So a very simple sample case seems to be using\n>>>> it for\n>>>> specifying GPIO as trigger source.\n>>>>\n>>>> Is this possible to mix various entries in a list assigned to single\n>>>> property?\n>>>> Let's say:\n>>>> trigger-sources =\n>>>> <&ohci_port1>,\n>>>> <&ehci_port1>,\n>>>> <&gpio 1 GPIO_ACTIVE_HIGH>;\n>>>\n>>> According to my knowledge all elements in the list are elements\n>>> of one array, no matter if they are comma separated or space separated\n>>> in \"<>\" brackets. DT maintainer would have to confirm that though.\n>>\n>> This matches my knowledge as well.\n>\n> Having that, we would be limited to a list of fixed size\n> tuples IMHO.\n\nThat sounds OK. Now I spent some time thinking about this I think it can work.\nFirst of all we may need something like #sources-cells to extend our property\nin the future.\nSecondly it should be possible to detect type of phandle node by trying things\none by one. We should be e.g. able to check is phandle is for GPIO by trying\nof_find_gpiochip_by_xlate.\n\n\n>>>> Is this possible to support this? If so, which function I can use to\n>>>> detect\n>>>> what is pointed by a phandle?\n>>>> I'm not that familiar with DT and I'm not sure how to handle this.\n>>>\n>>> I wonder if this is correct way to go. Maybe we should think of\n>>> creating entirely new trigger mechanism that would allow for having\n>>> multiple active triggers at a time.\n>>\n>> I'm OK with reworking Linux's triggers if it need be. I think we should\n>> agree\n>> on binding(s) first though.\n>\n> I was thinking of creating entirely new mechanism (new sysfs file),\n> as we can't break existing users.\n\nAgree.\n\n\n>>> Of course trigger-sources would be still useful for defining\n>>> a list of devices of the same type like in case of usbport trigger.\n>>> Nonetheless, I have a problem with this property being a part of\n>>> LED class device DT bindings. Triggers are not tightly coupled with\n>>> LED class devices, but trigger-sources being a list of usb ports\n>>> would be applicable only to usbport trigger. What if there was\n>>> another combo trigger e.g. for reporting activity on mulitple GPIOs?\n>>\n>> That was exactly my point with above trigger-sources example including 2\n>> USB\n>> ports & GPIO.\n>\n> How usbport trigger would make use use of information about GPIO?\n> Does it mean that in this approach triggers would arbitrarily choose\n> trigger-sources applicable for them?\n\nIt wouldn't. It would simply ignore it.\n\nWe could modify ledtrig-gpio.c however to support this new property\n(ex-\"led-triggers\") and make use of specified GPIO(s). Of course ledtrig-gpio\nwould ignore specified USB ports. One type per LED trigger driver.\n\n\n>>> Should we have separate list of trigger sources per any possible\n>>> existing trigger type? Aren't we going to far from pure hardware\n>>> description the Device Tree was initially predestined to?\n>>\n>> That would simplify things, but it gets us back to *multiple* properties\n>> like\n>> led-usb-triggers (or led-usb-trigger-sources)\n>> led-pci-triggers (or led-pci-trigger-sources)\n>> led-gpio-triggers (or led-gpio-trigger-sources)\n>> etc.\n>\n> Right, I was rather skeptical in my question - I don't like this\n> solution too.\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vDwTL4Z25z9ryb\n\tfor ;\n\tFri, 3 Feb 2017 10:00:54 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751985AbdBBXAv (ORCPT\n\t);\n\tThu, 2 Feb 2017 18:00:51 -0500","from mail-lf0-f66.google.com ([209.85.215.66]:36793 \"EHLO\n\tmail-lf0-f66.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751779AbdBBXAu (ORCPT\n\t); Thu, 2 Feb 2017 18:00:50 -0500","by mail-lf0-f66.google.com with SMTP id h65so164435lfi.3;\n\tThu, 02 Feb 2017 15:00:49 -0800 (PST)","from linux-samsung.lan\n\t(ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233])\n\tby smtp.googlemail.com with ESMTPSA id\n\tl133sm7051850lfg.40.2017.02.02.15.00.46\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 02 Feb 2017 15:00:47 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"IMPlzlHL\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=9mggG16HJeM4juJ00GplVZbS//HchNHg2K5kzPdTDVU=;\n\tb=IMPlzlHL1rI+obgZWHIngiZ11WVFBe4dwYX2aSIs2I7WYs/njnSSV5UMwTBnKQHIaX\n\taG8uoTpd9+i3U0QTnM19QeuQesGJaelj0GimBxujKZDSA/A4N8LHTXwFo2ArPhmkX2jk\n\tVlNR1O8plmKIALNpetoYoaIVaVJcbSgEcp8oAv/E2+wHRJOAsQUMgEpfq1uXJxqyJLvY\n\t0UtVKDqO/IvXL51fXIdJQZRkoVJ9viNHvCI28cNnRry5yTVT9YerGHPSR4WLTmgGH1G8\n\tmkMxl8HYemrYZQsRQFOFltBtWEBzAeB0q9T/adTITFNEFCLyiWTvjl845EijQb1fYVGe\n\t5BwQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=9mggG16HJeM4juJ00GplVZbS//HchNHg2K5kzPdTDVU=;\n\tb=ZyQP9E64BmGHPDdbr1fCzK81SOT6MvvtWomzU2GRO9V5tRC02W2Sg1/teNDS7lc9Ey\n\ttlYg60CVhgN34WwSfbRjUexk/Rl8pQ05hUnwtDvkDrxt0jTv8Hs0TWHMWCjG/C/9yrpI\n\tsgPiYUN2UOal3FyAvUJ1N+9OZXiNRuS0scq2g8t3Ad0H/blCG/xwZla+4e+1Wum/pTss\n\t+yJTmUq+X7U7AxK3u2xPqTLIrJaP4pvMl6uNlVN5AHd1YovrZYEqC+v4PsqUHYWVh/Pe\n\tFAHps6Wbsy9m5Pl5qyIp2S9VpBZLUcjWH+RDtsB2UooEi9OwzywojqgjJ6qVX/RJ9s0Q\n\tNWtw==","X-Gm-Message-State":"AIkVDXIMZGezNfrbnIPqLsnTW4RpExxwNc/670+4A9rkwjRmngFVzzDNhQ4cDA2qbQwWzg==","X-Received":"by 10.25.38.136 with SMTP id m130mr4049929lfm.90.1486076447913; \n\tThu, 02 Feb 2017 15:00:47 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"Jacek Anaszewski ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t\n\t<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>\n\t<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tMark Rutland ","From":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Message-ID":"","Date":"Fri, 3 Feb 2017 00:00:46 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1573685,"web_url":"http://patchwork.ozlabs.org/comment/1573685/","msgid":"<20170203110510.GB30941@amd>","list_archive_url":null,"date":"2017-02-03T11:05:10","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> >>>>Is this possible to mix various entries in a list assigned to single\n> >>>>property?\n> >>>>Let's say:\n> >>>>trigger-sources =\n> >>>> <&ohci_port1>,\n> >>>> <&ehci_port1>,\n> >>>> <&gpio 1 GPIO_ACTIVE_HIGH>;\n\nActually... I'm not sure I like the \"multiple sources\". It is somehow\njustified for ohci/ehci_port, because they... represent single\nphysical port. Could we introduce something for the physical port into\nthe DTS, too?\n\n> >>>According to my knowledge all elements in the list are elements\n> >>>of one array, no matter if they are comma separated or space separated\n> >>>in \"<>\" brackets. DT maintainer would have to confirm that though.\n> >>\n> >>This matches my knowledge as well.\n> >\n> >Having that, we would be limited to a list of fixed size\n> >tuples IMHO.\n> \n> That sounds OK. Now I spent some time thinking about this I think it can work.\n> First of all we may need something like #sources-cells to extend our property\n> in the future.\n> Secondly it should be possible to detect type of phandle node by trying things\n> one by one. We should be e.g. able to check is phandle is for GPIO by trying\n> of_find_gpiochip_by_xlate.\n\nI am not sure if variable-length parameters here is good idea. Would\nbe nice to keep it simple... Having the led representing voltage on\ngpio line is somehow strange to me. I'd rather have dts explaining\nwhat that voltage means (\"it is battery charging signal\") and than\nhave led connected to that...\n\t\t\t\t\t\t\t\t\tPavel","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vFDY865NSz9s7D\n\tfor ;\n\tFri, 3 Feb 2017 22:05:16 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752341AbdBCLFO (ORCPT\n\t);\n\tFri, 3 Feb 2017 06:05:14 -0500","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:32924 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752238AbdBCLFO (ORCPT\n\t); Fri, 3 Feb 2017 06:05:14 -0500","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid 835A68177C; Fri, 3 Feb 2017 12:05:11 +0100 (CET)"],"Date":"Fri, 3 Feb 2017 12:05:10 +0100","From":"Pavel Machek ","To":"=?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Cc":"Jacek Anaszewski ,\n\tRob Herring ,\n\tGreg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie ,\n\t\"devicetree@vger.kernel.org\" ,\n\tMark Rutland ","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","Message-ID":"<20170203110510.GB30941@amd>","References":"<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t\n\t<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>\n\t<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>\n\t\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"/NkBOFFp2J2Af1nK\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1577593,"web_url":"http://patchwork.ozlabs.org/comment/1577593/","msgid":"<630fd822-e95a-b0db-4da2-ddea9eaf0b1e@gmail.com>","list_archive_url":null,"date":"2017-02-07T21:41:25","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 02/03/2017 12:00 AM, Rafał Miłecki wrote:\n> On 02/02/2017 09:44 PM, Jacek Anaszewski wrote:\n>> On 02/01/2017 10:55 PM, Rafał Miłecki wrote:\n>>> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:\n>>>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:\n>>>>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n>>>>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>>>>>>> Thanks a lot Jacek for this explanation (and sorry but I needed a\n>>>>>>> bit of\n>>>>>>> time to\n>>>>>>> think about this). I can finally see your point, I think we're on\n>>>>>>> the\n>>>>>>> same page\n>>>>>>> now.\n>>>>>>>\n>>>>>>> I think that for all this time I was thinking from the pure DT\n>>>>>>> perspective. If\n>>>>>>> you ignore fact that Linux has multiple LED trigger drivers, then\n>>>>>>> \"led-triggers\"\n>>>>>>> may not sound that bad.\n>>>>>>>\n>>>>>>> After reading your description however I can see this property\n>>>>>>> can be\n>>>>>>> misleading\n>>>>>>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>>>>>>\n>>>>>>> I still think this is a useful property and I hope we can still\n>>>>>>> find a\n>>>>>>> way to\n>>>>>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>>>>>>> subsystem.\n>>>>>>\n>>>>>> I also see the need for this property.\n>>>>>>\n>>>>>>> I think we should still work on some generic property (without\n>>>>>>> linux,\n>>>>>>> prefix) as\n>>>>>>> this seems to be something generic, not really specific to Linux\n>>>>>>> implementation.\n>>>>>>> Specifying relation between LED and devices is something than AFAICS\n>>>>>>> can be\n>>>>>>> reused by other systems as well.\n>>>>>>>\n>>>>>>> So my suggestion is to try some new name & leave\n>>>>>>> linux,default-trigger\n>>>>>>> to allow\n>>>>>>> specifying one single trigger driver as required by current Linux\n>>>>>>> implementation.\n>>>>>>>\n>>>>>>> What do you think about this?\n>>>>>>>\n>>>>>>> There are few suggestions to came to my mind:\n>>>>>>> \"trigger-sources\"\n>>>>>>> \"trigger-devices\"\n>>>>>>> \"led-trigger-devices\"\n>>>>>>> \"led-related-devices\"\n>>>>>>> \"led-event-devices\"\n>>>>>>\n>>>>>> trigger-devices would work in this specific use case,\n>>>>>> where we can give phandles to usb ports. Nonetheless, we\n>>>>>> have also other kernel based events serving as trigger\n>>>>>> sources - e.g. timer.\n>>>>>>\n>>>>>> In this case I'd go for trigger-sources, but we'd need\n>>>>>> to have some generic way of defining the source like timer.\n>>>>>\n>>>>> I'd leave timer for later discussion but I'm glad you brought this\n>>>>> problem.\n>>>>> Maybe we could discuss this on another example that is more supported\n>>>>> like\n>>>>> GPIOs?\n>>>>>\n>>>>> We know this property allows specifying USB ports and we want it to\n>>>>> support\n>>>>> mixing various sources. So a very simple sample case seems to be using\n>>>>> it for\n>>>>> specifying GPIO as trigger source.\n>>>>>\n>>>>> Is this possible to mix various entries in a list assigned to single\n>>>>> property?\n>>>>> Let's say:\n>>>>> trigger-sources =\n>>>>> <&ohci_port1>,\n>>>>> <&ehci_port1>,\n>>>>> <&gpio 1 GPIO_ACTIVE_HIGH>;\n>>>>\n>>>> According to my knowledge all elements in the list are elements\n>>>> of one array, no matter if they are comma separated or space separated\n>>>> in \"<>\" brackets. DT maintainer would have to confirm that though.\n>>>\n>>> This matches my knowledge as well.\n>>\n>> Having that, we would be limited to a list of fixed size\n>> tuples IMHO.\n> \n> That sounds OK. Now I spent some time thinking about this I think it can\n> work.\n> First of all we may need something like #sources-cells to extend our\n> property\n> in the future.\n> Secondly it should be possible to detect type of phandle node by trying\n> things\n> one by one. We should be e.g. able to check is phandle is for GPIO by\n> trying\n> of_find_gpiochip_by_xlate.\n> \n> \n>>>>> Is this possible to support this? If so, which function I can use to\n>>>>> detect\n>>>>> what is pointed by a phandle?\n>>>>> I'm not that familiar with DT and I'm not sure how to handle this.\n>>>>\n>>>> I wonder if this is correct way to go. Maybe we should think of\n>>>> creating entirely new trigger mechanism that would allow for having\n>>>> multiple active triggers at a time.\n>>>\n>>> I'm OK with reworking Linux's triggers if it need be. I think we should\n>>> agree\n>>> on binding(s) first though.\n>>\n>> I was thinking of creating entirely new mechanism (new sysfs file),\n>> as we can't break existing users.\n> \n> Agree.\n> \n> \n>>>> Of course trigger-sources would be still useful for defining\n>>>> a list of devices of the same type like in case of usbport trigger.\n>>>> Nonetheless, I have a problem with this property being a part of\n>>>> LED class device DT bindings. Triggers are not tightly coupled with\n>>>> LED class devices, but trigger-sources being a list of usb ports\n>>>> would be applicable only to usbport trigger. What if there was\n>>>> another combo trigger e.g. for reporting activity on mulitple GPIOs?\n>>>\n>>> That was exactly my point with above trigger-sources example including 2\n>>> USB\n>>> ports & GPIO.\n>>\n>> How usbport trigger would make use use of information about GPIO?\n>> Does it mean that in this approach triggers would arbitrarily choose\n>> trigger-sources applicable for them?\n> \n> It wouldn't. It would simply ignore it.\n> \n> We could modify ledtrig-gpio.c however to support this new property\n> (ex-\"led-triggers\") and make use of specified GPIO(s). Of course\n> ledtrig-gpio\n> would ignore specified USB ports. One type per LED trigger driver.\n\nFrankly speaking I don't like this too much. It would be hard\nto infer from the bindings which trigger sources will be used by which\ntrigger.\n\nI'd like to propose something different, i.e. trigger specific\ntrigger-sources property, but defined in a separate DT node\nfor each LED trigger:\n\nled1-usbport-trig: usbport-trig {\n\ttrigger-type = \"usbport\";\n\ttrigger-sources = <&usb-port1>, <&usb-port2>, ;\n\tled-dev = <&led1>;\n};\n\nled1-compound-gpio-trig: compound-gpio-trig {\n\ttrigger-type = \"oneshot\";\n\ttrigger-sources = <&gpio1>, <&gpio2>, <&gpio3>;\n\tled-dev = <&led1>;\n};\n\nled1: led1 {\n\tcompound-triggers = <&led1-usbport-trig>. <&led1-compound-gpio-trig>;\n}\n\nThis way when applying usbport trigger to led1, we would know how\nto configure it for this particular LED. If we had led2, we could\ndefine different subset of usb ports to trigger it. In case of\nhypothetical compound-gpio trigger, the driver would know\nwhich gpios should generate LED events.\n\nThis is a freshly devised idea, just a subject for a discussion.\n\nBest regards,\nJacek Anaszewski\n\n>>>> Should we have separate list of trigger sources per any possible\n>>>> existing trigger type? Aren't we going to far from pure hardware\n>>>> description the Device Tree was initially predestined to?\n>>>\n>>> That would simplify things, but it gets us back to *multiple* properties\n>>> like\n>>> led-usb-triggers (or led-usb-trigger-sources)\n>>> led-pci-triggers (or led-pci-trigger-sources)\n>>> led-gpio-triggers (or led-gpio-trigger-sources)\n>>> etc.\n>>\n>> Right, I was rather skeptical in my question - I don't like this\n>> solution too.\n> \n\n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vHyWQ0Wpmz9ryb\n\tfor ;\n\tWed, 8 Feb 2017 08:43:14 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932333AbdBGVnG (ORCPT );\n\tTue, 7 Feb 2017 16:43:06 -0500","from mail-wm0-f67.google.com ([74.125.82.67]:36830 \"EHLO\n\tmail-wm0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S932076AbdBGVnD (ORCPT\n\t); Tue, 7 Feb 2017 16:43:03 -0500","by mail-wm0-f67.google.com with SMTP id r18so30801819wmd.3;\n\tTue, 07 Feb 2017 13:42:13 -0800 (PST)","from [192.168.1.17] (agqk131.neoplus.adsl.tpnet.pl.\n\t[217.99.36.131]) by smtp.gmail.com with ESMTPSA id\n\tm84sm700032wmf.10.2017.02.07.13.42.10\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 07 Feb 2017 13:42:11 -0800 (PST)"],"Authentication-Results":"ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"VMPvh2mS\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=S7l6oYQ/XS6tnz5KmKwDiO8LzVXv69AO50NpZHTwNV0=;\n\tb=VMPvh2mSfWwGxByHFY+Y2ZyDf7IGJeAGtGtSXFdkeBCQjSdVeES46slbYar7QqUs2s\n\tXXxKS4sLKpwfhO0YIC3QodaGRdpK1Zm9c8VJPXTeECy+1e+NVgTuMF/AAGYwnTQmC5/C\n\tmj0TXyiEqFkoRX0SZiM3KJU2to5OmZUinrWMgxB6x4SnWgTxnc4RDIDQRpwiEnKnokN9\n\t5WEZbHTVxDFS1vuBOgZ87dWxgX0gbOGEZGq9aY5abe1eVqX+cBZvtyStEXXXqLeGzoJ9\n\tpg1nde52C8zcdSXN30QEP1ffaEweMby4a423OkVIIzbJeH7Qt16VkcupPeGSndQJ18sN\n\tT68Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:references:cc:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding;\n\tbh=S7l6oYQ/XS6tnz5KmKwDiO8LzVXv69AO50NpZHTwNV0=;\n\tb=iFEo54hdTnUoGe5Oe3e1V6d2+zYbC4U/+hPWJXnKP5QDCU9PkAfXivRB56O3wkh4pD\n\t6WaLrMr9qzYoydiCueFOv5b4MHAuLF1pD1yWsf1yBL8SYEc7yfTsJ8Lry3AE9jWAEd7M\n\tbI05SOIng5IfP3ML1wf5uRxDqtPY6hT/fD3uOirVz9b+JLNcmPn6ou7UbGAqZOBoCWN7\n\tw4O5Q+tIPnaedPya4iWioHnVZdCfeRixwR29ziGvXdNNCBqU8BgfcfEdfhcA1UEqCkDW\n\tuoUno+hAxXNO/vMtp2IMjhqW7VXoFmJL1cHDhaWrTaI8IotCVqxex5WqZIAGO8GvFfPT\n\t3Tng==","X-Gm-Message-State":"AMke39n35kvPGAnQO0/FnPByDnIXvLqNoWSbGw787qwLoLQ2Gsf+sEqzf73iwXpGjpfUmg==","X-Received":"by 10.28.197.77 with SMTP id v74mr16084142wmf.30.1486503732548; \n\tTue, 07 Feb 2017 13:42:12 -0800 (PST)","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ,\n\tRob Herring ","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t\n\t<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>\n\t<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>\n\t\n\t","Cc":"Greg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tMark Rutland ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<630fd822-e95a-b0db-4da2-ddea9eaf0b1e@gmail.com>","Date":"Tue, 7 Feb 2017 22:41:25 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tIcedove/45.5.1","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1577703,"web_url":"http://patchwork.ozlabs.org/comment/1577703/","msgid":"","list_archive_url":null,"date":"2017-02-07T22:57:04","subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","submitter":{"id":67416,"url":"http://patchwork.ozlabs.org/api/people/67416/","name":"Rob Herring","email":"robh+dt@kernel.org"},"content":"On Wed, Feb 1, 2017 at 3:55 PM, Rafał Miłecki wrote:\n> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:\n>>\n>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:\n>>>\n>>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:\n>>>>\n>>>> On 01/31/2017 05:11 PM, Rafał Miłecki wrote:\n>>>>>\n>>>>> Thanks a lot Jacek for this explanation (and sorry but I needed a bit\n>>>>> of\n>>>>> time to\n>>>>> think about this). I can finally see your point, I think we're on the\n>>>>> same page\n>>>>> now.\n>>>>>\n>>>>> I think that for all this time I was thinking from the pure DT\n>>>>> perspective. If\n>>>>> you ignore fact that Linux has multiple LED trigger drivers, then\n>>>>> \"led-triggers\"\n>>>>> may not sound that bad.\n>>>>>\n>>>>> After reading your description however I can see this property can be\n>>>>> misleading\n>>>>> as Linux people may think \"drivers\" when seeing \"triggers\".\n>>>>>\n>>>>> I still think this is a useful property and I hope we can still find a\n>>>>> way to\n>>>>> name it in a sane way: to be nice from DT PoV and march Linux LEDs\n>>>>> subsystem.\n>>>>\n>>>>\n>>>> I also see the need for this property.\n>>>>\n>>>>> I think we should still work on some generic property (without linux,\n>>>>> prefix) as\n>>>>> this seems to be something generic, not really specific to Linux\n>>>>> implementation.\n>>>>> Specifying relation between LED and devices is something than AFAICS\n>>>>> can be\n>>>>> reused by other systems as well.\n>>>>>\n>>>>> So my suggestion is to try some new name & leave linux,default-trigger\n>>>>> to allow\n>>>>> specifying one single trigger driver as required by current Linux\n>>>>> implementation.\n>>>>>\n>>>>> What do you think about this?\n>>>>>\n>>>>> There are few suggestions to came to my mind:\n>>>>> \"trigger-sources\"\n>>>>> \"trigger-devices\"\n>>>>> \"led-trigger-devices\"\n>>>>> \"led-related-devices\"\n>>>>> \"led-event-devices\"\n>>>>\n>>>>\n>>>> trigger-devices would work in this specific use case,\n>>>> where we can give phandles to usb ports. Nonetheless, we\n>>>> have also other kernel based events serving as trigger\n>>>> sources - e.g. timer.\n>>>>\n>>>> In this case I'd go for trigger-sources, but we'd need\n>>>> to have some generic way of defining the source like timer.\n\n+1 for the name.\n\n>>>\n>>>\n>>> I'd leave timer for later discussion but I'm glad you brought this\n>>> problem.\n>>> Maybe we could discuss this on another example that is more supported\n>>> like\n>>> GPIOs?\n>>>\n>>> We know this property allows specifying USB ports and we want it to\n>>> support\n>>> mixing various sources. So a very simple sample case seems to be using\n>>> it for\n>>> specifying GPIO as trigger source.\n>>>\n>>> Is this possible to mix various entries in a list assigned to single\n>>> property?\n>>> Let's say:\n>>> trigger-sources =\n>>> <&ohci_port1>,\n>>> <&ehci_port1>,\n>>> <&gpio 1 GPIO_ACTIVE_HIGH>;\n>>\n>>\n>> According to my knowledge all elements in the list are elements\n>> of one array, no matter if they are comma separated or space separated\n>> in \"<>\" brackets. DT maintainer would have to confirm that though.\n>\n>\n> This matches my knowledge as well.\n\nIt is a bit problematic, but this could work as long as you know the\npossible arg types and a given node only has 1 match (nodes with\ninterrupt and gpio being likely). You look up the phandle, iterate\nthru possible \"#*-cells\" properties for that phandle, then parse the\ncells. You could define rules of what is the required cell type (e.g.\nmust use gpio cells if a phandle has both gpio and interrupt cells\ndefined.).\n\nAnother, simpler approach would be defining #trigger-cells in each\nsource. This is probably the better option as all the infrastructure\nis there and could handle unforeseen cases.\n\n>>> Is this possible to support this? If so, which function I can use to\n>>> detect\n>>> what is pointed by a phandle?\n>>> I'm not that familiar with DT and I'm not sure how to handle this.\n>>\n>>\n>> I wonder if this is correct way to go. Maybe we should think of\n>> creating entirely new trigger mechanism that would allow for having\n>> multiple active triggers at a time.\n>\n>\n> I'm OK with reworking Linux's triggers if it need be. I think we should\n> agree\n> on binding(s) first though.\n\nYes, they are separate problems.\n\nRob\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3vJ09M367qz9s2s\n\tfor ;\n\tWed, 8 Feb 2017 09:57:43 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932415AbdBGW5g convert rfc822-to-8bit (ORCPT\n\t);\n\tTue, 7 Feb 2017 17:57:36 -0500","from mail.kernel.org ([198.145.29.136]:38512 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S932379AbdBGW5f (ORCPT );\n\tTue, 7 Feb 2017 17:57:35 -0500","from mail.kernel.org (localhost [127.0.0.1])\n\tby mail.kernel.org (Postfix) with ESMTP id 46D95203A5;\n\tTue, 7 Feb 2017 22:57:28 +0000 (UTC)","from mail-yw0-f174.google.com (mail-yw0-f174.google.com\n\t[209.85.161.174])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 076BD20253;\n\tTue, 7 Feb 2017 22:57:26 +0000 (UTC)","by mail-yw0-f174.google.com with SMTP id w75so76153209ywg.1;\n\tTue, 07 Feb 2017 14:57:25 -0800 (PST)","by 10.13.212.12 with HTTP; Tue, 7 Feb 2017 14:57:04 -0800 (PST)"],"X-Gm-Message-State":"AIkVDXJ24BgqI9GoXEHnCqrmwY75ogKa9q3CQYqUx0N9wNyYMkF4znKGQfNTahCeXkVP9cbyzxh5/lILmnI/Lg==","X-Received":"by 10.129.183.23 with SMTP id v23mr12082931ywh.257.1486508245209;\n\tTue, 07 Feb 2017 14:57:25 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>","References":"<20170120215605.15728-1-zajec5@gmail.com>\n\t<29f27028-20f3-3eb9-502f-1b51958640f9@gmail.com>\n\t\n\t<46084d98-fddb-1b92-e9ca-d55957a442ae@gmail.com>\n\t\n\t\n\t\n\t\n\t\n\t<93896405-5ee0-ea85-72b1-5774c13a0c36@gmail.com>\n\t<438140b2-896f-6a58-2529-9d30db6d4fde@gmail.com>","From":"Rob Herring ","Date":"Tue, 7 Feb 2017 16:57:04 -0600","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers\n\tproperty","To":"=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= ","Cc":"Jacek Anaszewski ,\n\tGreg Kroah-Hartman ,\n\t\"linux-usb@vger.kernel.org\" ,\n\t\"open list:LED SUBSYSTEM\" ,\n\tRichard Purdie , Pavel Machek ,\n\t\"devicetree@vger.kernel.org\" ,\n\tMark Rutland ","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8BIT","X-Spam-Status":"No, score=-1.9 required=5.0 tests=BAYES_00, UNPARSEABLE_RELAY\n\tautolearn=unavailable version=3.3.1","X-Spam-Checker-Version":"SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org","X-Virus-Scanned":"ClamAV using ClamSMTP","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]