[{"id":1770078,"web_url":"http://patchwork.ozlabs.org/comment/1770078/","msgid":"<20170918105655.GA14591@amd>","list_archive_url":null,"date":"2017-09-18T10:56:55","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> Specify the exact label used if the label property is omitted in DT, as\n> well as use label in the example that conforms to LED device naming.\n> \n> @@ -69,11 +73,11 @@ Example\n> \t\t\tflash-max-microamp = <320000>;\n> \t\t\tled-max-microamp = <60000>;\n> \t\t\tams,input-max-microamp = <1750000>;\n> -\t\t\tlabel = \"as3645a:flash\";\n> +\t\t\tlabel = \"as3645a:white:flash\";\n> \t\t};\n> \t\tindicator@1 {\n> \t\t\treg = <0x1>;\n> \t\t\tled-max-microamp = <10000>;\n> -\t\t\tlabel = \"as3645a:indicator\";\n> +\t\t\tlabel = \"as3645a:red:indicator\";\n> \t\t};\n> \t};\n\nOk, but userspace still has no chance to determine if this is flash\nfrom main camera or flash for front camera; todays smartphones have\nflashes on both cameras.\n\nSo.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n....?\n\nThanks,\n\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","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwjd70RkWz9s7M\n\tfor ;\n\tMon, 18 Sep 2017 20:57:15 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754663AbdIRK5M (ORCPT\n\t);\n\tMon, 18 Sep 2017 06:57:12 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:32950 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751924AbdIRK47 (ORCPT\n\t); Mon, 18 Sep 2017 06:56:59 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid 4F440824D5; Mon, 18 Sep 2017 12:56:56 +0200 (CEST)"],"Date":"Mon, 18 Sep 2017 12:56:55 +0200","From":"Pavel Machek ","To":"Sakari Ailus ","Cc":"linux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","Message-ID":"<20170918105655.GA14591@amd>","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"J/dobhs11T7y2rNN\"","Content-Disposition":"inline","In-Reply-To":"<20170918102349.8935-5-sakari.ailus@linux.intel.com>","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":1770219,"web_url":"http://patchwork.ozlabs.org/comment/1770219/","msgid":"<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-18T14:49:23","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Hi Pavel,\n\nOn Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n> Hi!\n> \n> > Specify the exact label used if the label property is omitted in DT, as\n> > well as use label in the example that conforms to LED device naming.\n> > \n> > @@ -69,11 +73,11 @@ Example\n> > \t\t\tflash-max-microamp = <320000>;\n> > \t\t\tled-max-microamp = <60000>;\n> > \t\t\tams,input-max-microamp = <1750000>;\n> > -\t\t\tlabel = \"as3645a:flash\";\n> > +\t\t\tlabel = \"as3645a:white:flash\";\n> > \t\t};\n> > \t\tindicator@1 {\n> > \t\t\treg = <0x1>;\n> > \t\t\tled-max-microamp = <10000>;\n> > -\t\t\tlabel = \"as3645a:indicator\";\n> > +\t\t\tlabel = \"as3645a:red:indicator\";\n> > \t\t};\n> > \t};\n> \n> Ok, but userspace still has no chance to determine if this is flash\n> from main camera or flash for front camera; todays smartphones have\n> flashes on both cameras.\n> \n> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n> ....?\n\nIf there's just a single one in the device, could you use that?\n\nEven if we name this so for N9 (and N900), the application still would only\nwork with the two devices.\n\nMy suggestion would be to look for a flash LED, and perhaps the maximum\ncurrent as well. That should generally work better than assumptions on the\nlabel.\n\nFor association with a particular camera --- in the long run I'd propose to\nuse Media controller / property API for that in the long run. We don't have\nthat yet though.\n\nCc Jacek, too.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwpn50Jfwz9s78\n\tfor ;\n\tTue, 19 Sep 2017 00:49:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932106AbdIROt1 (ORCPT );\n\tMon, 18 Sep 2017 10:49:27 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:48334 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S932102AbdIROt0 (ORCPT\n\t); Mon, 18 Sep 2017 10:49:26 -0400","from valkosipuli.localdomain (valkosipuli.retiisi.org.uk\n\t[IPv6:2001:1bc8:1a6:d3d5::80:2])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 29DD760130;\n\tMon, 18 Sep 2017 17:49:24 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1dtxMR-0004x9-Pj; Mon, 18 Sep 2017 17:49:23 +0300"],"Date":"Mon, 18 Sep 2017 17:49:23 +0300","From":"Sakari Ailus ","To":"Pavel Machek ","Cc":"Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org, jacek.anaszewski@gmail.com","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","Message-ID":"<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170918105655.GA14591@amd>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1770486,"web_url":"http://patchwork.ozlabs.org/comment/1770486/","msgid":"<20170918205407.GA1849@amd>","list_archive_url":null,"date":"2017-09-18T20:54:07","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:\n> Hi Pavel,\n> \n> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n> > Hi!\n> > \n> > > Specify the exact label used if the label property is omitted in DT, as\n> > > well as use label in the example that conforms to LED device naming.\n> > > \n> > > @@ -69,11 +73,11 @@ Example\n> > > \t\t\tflash-max-microamp = <320000>;\n> > > \t\t\tled-max-microamp = <60000>;\n> > > \t\t\tams,input-max-microamp = <1750000>;\n> > > -\t\t\tlabel = \"as3645a:flash\";\n> > > +\t\t\tlabel = \"as3645a:white:flash\";\n> > > \t\t};\n> > > \t\tindicator@1 {\n> > > \t\t\treg = <0x1>;\n> > > \t\t\tled-max-microamp = <10000>;\n> > > -\t\t\tlabel = \"as3645a:indicator\";\n> > > +\t\t\tlabel = \"as3645a:red:indicator\";\n> > > \t\t};\n> > > \t};\n> > \n> > Ok, but userspace still has no chance to determine if this is flash\n> > from main camera or flash for front camera; todays smartphones have\n> > flashes on both cameras.\n> > \n> > So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n> > ....?\n> \n> If there's just a single one in the device, could you use that?\n> \n> Even if we name this so for N9 (and N900), the application still would only\n> work with the two devices.\n\nWell, I'd plan to name it on other devices, too.\n\n> My suggestion would be to look for a flash LED, and perhaps the maximum\n> current as well. That should generally work better than assumptions on the\n> label.\n\nIf you just look for flash LED, you don't know if it is front one or\nback one. Its true that if you have just one flash it is usually on\nthe back camera, but you can't know if maybe driver is not available\nfor the main flash.\n\nLets get this right, please \"main_camera_flash\" is 12 bytes more than\n\"flash\", and it saves application logic.. more than 12 bytes, I'm sure. \n\n> For association with a particular camera --- in the long run I'd propose to\n> use Media controller / property API for that in the long run. We don't have\n> that yet though.\n\nWe don't have that yet. Plus simple applications may not want to talk\nv4l2 ioctls....\n\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","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwyt242Bxz9s7p\n\tfor ;\n\tTue, 19 Sep 2017 06:54:18 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751309AbdIRUyM (ORCPT\n\t);\n\tMon, 18 Sep 2017 16:54:12 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:53792 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750714AbdIRUyJ (ORCPT\n\t); Mon, 18 Sep 2017 16:54:09 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid C9F34824D5; Mon, 18 Sep 2017 22:54:07 +0200 (CEST)"],"Date":"Mon, 18 Sep 2017 22:54:07 +0200","From":"Pavel Machek ","To":"Sakari Ailus ","Cc":"Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org, jacek.anaszewski@gmail.com","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","Message-ID":"<20170918205407.GA1849@amd>","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>\n\t<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"oyUTqETQ0mS9luUI\"","Content-Disposition":"inline","In-Reply-To":"<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>","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":1771393,"web_url":"http://patchwork.ozlabs.org/comment/1771393/","msgid":"<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>","list_archive_url":null,"date":"2017-09-19T21:01:02","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"Hi Pavel,\n\nOn 09/18/2017 10:54 PM, Pavel Machek wrote:\n> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:\n>> Hi Pavel,\n>>\n>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n>>> Hi!\n>>>\n>>>> Specify the exact label used if the label property is omitted in DT, as\n>>>> well as use label in the example that conforms to LED device naming.\n>>>>\n>>>> @@ -69,11 +73,11 @@ Example\n>>>> \t\t\tflash-max-microamp = <320000>;\n>>>> \t\t\tled-max-microamp = <60000>;\n>>>> \t\t\tams,input-max-microamp = <1750000>;\n>>>> -\t\t\tlabel = \"as3645a:flash\";\n>>>> +\t\t\tlabel = \"as3645a:white:flash\";\n>>>> \t\t};\n>>>> \t\tindicator@1 {\n>>>> \t\t\treg = <0x1>;\n>>>> \t\t\tled-max-microamp = <10000>;\n>>>> -\t\t\tlabel = \"as3645a:indicator\";\n>>>> +\t\t\tlabel = \"as3645a:red:indicator\";\n>>>> \t\t};\n>>>> \t};\n>>>\n>>> Ok, but userspace still has no chance to determine if this is flash\n>>> from main camera or flash for front camera; todays smartphones have\n>>> flashes on both cameras.\n>>>\n>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n>>> ....?\n>>\n>> If there's just a single one in the device, could you use that?\n>>\n>> Even if we name this so for N9 (and N900), the application still would only\n>> work with the two devices.\n> \n> Well, I'd plan to name it on other devices, too.\n> \n>> My suggestion would be to look for a flash LED, and perhaps the maximum\n>> current as well. That should generally work better than assumptions on the\n>> label.\n> \n> If you just look for flash LED, you don't know if it is front one or\n> back one. Its true that if you have just one flash it is usually on\n> the back camera, but you can't know if maybe driver is not available\n> for the main flash.\n> \n> Lets get this right, please \"main_camera_flash\" is 12 bytes more than\n> \"flash\", and it saves application logic.. more than 12 bytes, I'm sure. \n\nWhat you are trying to introduce is yet another level of LED class\ndevice naming standard, one level below devicename:colour:function.\nIt seems you want also to come up with the set of standarized LED\nfunction names. This would certainly have to be covered for consistency.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","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=\"efI0pKZK\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xxb0S09Bgz9sMN\n\tfor ;\n\tWed, 20 Sep 2017 07:02:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751408AbdISVB6 (ORCPT\n\t);\n\tTue, 19 Sep 2017 17:01:58 -0400","from mail-wr0-f182.google.com ([209.85.128.182]:45778 \"EHLO\n\tmail-wr0-f182.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751367AbdISVB5 (ORCPT\n\t); Tue, 19 Sep 2017 17:01:57 -0400","by mail-wr0-f182.google.com with SMTP id m18so641797wrm.2;\n\tTue, 19 Sep 2017 14:01:56 -0700 (PDT)","from [192.168.1.18] (dnq205.neoplus.adsl.tpnet.pl. [83.24.98.205])\n\tby smtp.gmail.com with ESMTPSA id\n\tl126sm182525wmd.1.2017.09.19.14.01.53\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 19 Sep 2017 14:01:54 -0700 (PDT)"],"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=ftOzCz3Eo/Zd9d8+7cL/PjSo8xUD7gsbDgUuhb2Ko3M=;\n\tb=efI0pKZKKWDmLezHW69bPaneaaqnvA8IQGlJOKBlUCNtbGkHBux2JihSBTG5IaoYoJ\n\tUa0dpGbicoJtULMr8CFnQhruydBEL15800qgpxXFe6WV4CJu8Di4gX7+XZtlHasBcyYS\n\t2LcELTSIhrXN6mRxjrs1mUSehsC8e66SweW7SIXCXv5POh8CwygaUoFx/yz99op4T9s3\n\t5elwX+XwvKXgw/kff9nm7elwiL9KO6Lbm/8UO5y3cvnfMNzKUx/9kL5CKkISLopfhSpn\n\tSXqFZwXSHvLHSQ9MV+9eX/OjyhFzdTkiY34Bw0o7uopRFJQ8gUL6s3iN67BFNjeTtRLU\n\tBRRA==","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=ftOzCz3Eo/Zd9d8+7cL/PjSo8xUD7gsbDgUuhb2Ko3M=;\n\tb=Zvuf6dJ2Bz1MnjQ0lMcaQ5noHQqGbXby+DyJ3wxhJzNy+X0OtK/roC3kR5f085lz7+\n\tjL3j4I3VgfjuM1hZmJq9PFT9gwengCOjvucb3o3Bla2XhZsbQSxKEXq3Zy79Osp7BULE\n\t3hK+19WWxcYYs7hz8pfxljBb91ms3UsUU05ZcrOBHul5HesoFNoEMZ2RojSW08IKXSRB\n\tqySnB/R8c9MY7nc0fkXYQjGW/hRIoWIj4GFoaLKPBHN/3SL0m9WgSJbDJPBqbol4PxBe\n\tt5Efa9hTB+9qMumKg4nYwwM25/jha5gEoocztQ3WuxrCBPxToFr3N+vibjgE8CUDNTWN\n\tleew==","X-Gm-Message-State":"AHPjjUiwgkSxdIi57YFxGd01qziGiY/90a82BR0daiA14J/dRe697ORA\n\tyOFHKqRp2VVnPLQCLv1o6rAp97UZ","X-Google-Smtp-Source":"AOwi7QAwqDiOniMHiejhJiEmkePsdl3teeJZpnHUnjjSWXUJR4tAq4U3LVKs4Iq1byokMDWfTW/L6w==","X-Received":"by 10.223.142.82 with SMTP id n76mr2753459wrb.272.1505854915391; \n\tTue, 19 Sep 2017 14:01:55 -0700 (PDT)","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","To":"Pavel Machek , Sakari Ailus ","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>\n\t<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>\n\t<20170918205407.GA1849@amd>","Cc":"Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1010","Message-ID":"<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>","Date":"Tue, 19 Sep 2017 23:01:02 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170918205407.GA1849@amd>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1772199,"web_url":"http://patchwork.ozlabs.org/comment/1772199/","msgid":"<20170920205327.qmgz65kn45aavomx@rob-hp-laptop>","list_archive_url":null,"date":"2017-09-20T20:53:27","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:\n> Hi Pavel,\n> \n> On 09/18/2017 10:54 PM, Pavel Machek wrote:\n> > On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:\n> >> Hi Pavel,\n> >>\n> >> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n> >>> Hi!\n> >>>\n> >>>> Specify the exact label used if the label property is omitted in DT, as\n> >>>> well as use label in the example that conforms to LED device naming.\n> >>>>\n> >>>> @@ -69,11 +73,11 @@ Example\n> >>>> \t\t\tflash-max-microamp = <320000>;\n> >>>> \t\t\tled-max-microamp = <60000>;\n> >>>> \t\t\tams,input-max-microamp = <1750000>;\n> >>>> -\t\t\tlabel = \"as3645a:flash\";\n> >>>> +\t\t\tlabel = \"as3645a:white:flash\";\n> >>>> \t\t};\n> >>>> \t\tindicator@1 {\n> >>>> \t\t\treg = <0x1>;\n> >>>> \t\t\tled-max-microamp = <10000>;\n> >>>> -\t\t\tlabel = \"as3645a:indicator\";\n> >>>> +\t\t\tlabel = \"as3645a:red:indicator\";\n> >>>> \t\t};\n> >>>> \t};\n> >>>\n> >>> Ok, but userspace still has no chance to determine if this is flash\n> >>> from main camera or flash for front camera; todays smartphones have\n> >>> flashes on both cameras.\n> >>>\n> >>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n> >>> ....?\n> >>\n> >> If there's just a single one in the device, could you use that?\n> >>\n> >> Even if we name this so for N9 (and N900), the application still would only\n> >> work with the two devices.\n> > \n> > Well, I'd plan to name it on other devices, too.\n> > \n> >> My suggestion would be to look for a flash LED, and perhaps the maximum\n> >> current as well. That should generally work better than assumptions on the\n> >> label.\n> > \n> > If you just look for flash LED, you don't know if it is front one or\n> > back one. Its true that if you have just one flash it is usually on\n> > the back camera, but you can't know if maybe driver is not available\n> > for the main flash.\n> > \n> > Lets get this right, please \"main_camera_flash\" is 12 bytes more than\n> > \"flash\", and it saves application logic.. more than 12 bytes, I'm sure. \n> \n> What you are trying to introduce is yet another level of LED class\n> device naming standard, one level below devicename:colour:function.\n> It seems you want also to come up with the set of standarized LED\n> function names. This would certainly have to be covered for consistency.\n\nI really dislike how this naming convention is used for label. label is \nsupposed to be the phyically identifiable name. Having the devicename \ndefeats that. Perhaps color, too. We'd be better off with a color \nproperty. It seems we're overloading the naming with too many things. \nNow we're adding device association.\n\nI do want to see standard names though. On 96boards for example, there \nare defined LEDs and locations. The function on some are defined (e.g. \nWiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see \nthe same label across all boards.\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","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyBmG3Mm1z9s83\n\tfor ;\n\tThu, 21 Sep 2017 06:53:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751930AbdITUxb (ORCPT\n\t);\n\tWed, 20 Sep 2017 16:53:31 -0400","from mail-pf0-f194.google.com ([209.85.192.194]:38139 \"EHLO\n\tmail-pf0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751826AbdITUx3 (ORCPT\n\t); Wed, 20 Sep 2017 16:53:29 -0400","by mail-pf0-f194.google.com with SMTP id a7so1626247pfj.5;\n\tWed, 20 Sep 2017 13:53:29 -0700 (PDT)","from localhost ([2620:0:1000:fd28:e83d:5428:912b:b325])\n\tby smtp.gmail.com with ESMTPSA id\n\tx19sm12127194pfa.16.2017.09.20.13.53.27\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 20 Sep 2017 13:53:28 -0700 (PDT)"],"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:in-reply-to:user-agent;\n\tbh=ftCSuCD8ZrhGYMyftP3cKyyx2i2lreG4bhBIOLzKhUo=;\n\tb=jus+kc5KSdXyLOVrIiduhpcK2BzXauktwXfWf10K12hVu0Uhz2mEiJ90dhlkAKX3l8\n\t+jnSd0Rf3GgBhLB9Jv8llnySHCvmp3z5PtVDHpaNaX4YgJ9I0Cpq4XoT4O3lUObvkvGv\n\tBFFhTcpH1fzJz4L4ldk+VPOwziCyA67ctn7OgPM8z9vZYfwvbCDl5m9dZLOV9WIKD4Vw\n\tOz8KSbSuKVFU5g2a+rdEBHo3noORvh4w9yjT/ZbtBTymBeswhqu/CchBvAkk7aagrUsX\n\tACFsrZpR3frgzjCA34JlL8miRs/9J+qhhsbA8kaP7QJiyYQIJi9XVsFf+sO3AsoIKtO/\n\tRiiw==","X-Gm-Message-State":"AHPjjUiuZCyPYErh8FolPMWRFt16FPv0xkYzNIwXu5pmDI7P4pcgS6NF\n\t67U+1/DgGzxLlyMnNULW6LDcFTg=","X-Google-Smtp-Source":"AOwi7QDO1/SKlzQsRGNm/FLNRrFMkm0jaADPGQlelZ4/GD+eucgMsMPan6RBosRZYKkktnjNvj75Cw==","X-Received":"by 10.84.130.47 with SMTP id 44mr3273859plc.171.1505940808779;\n\tWed, 20 Sep 2017 13:53:28 -0700 (PDT)","Date":"Wed, 20 Sep 2017 15:53:27 -0500","From":"Rob Herring ","To":"Jacek Anaszewski ","Cc":"Pavel Machek , Sakari Ailus ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","Message-ID":"<20170920205327.qmgz65kn45aavomx@rob-hp-laptop>","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>\n\t<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>\n\t<20170918205407.GA1849@amd>\n\t<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773878,"web_url":"http://patchwork.ozlabs.org/comment/1773878/","msgid":"<6a6651f9-b5fb-0ec7-1f40-f72b1a630e70@gmail.com>","list_archive_url":null,"date":"2017-09-22T21:07:53","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 09/20/2017 10:53 PM, Rob Herring wrote:\n> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:\n>> Hi Pavel,\n>>\n>> On 09/18/2017 10:54 PM, Pavel Machek wrote:\n>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:\n>>>> Hi Pavel,\n>>>>\n>>>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n>>>>> Hi!\n>>>>>\n>>>>>> Specify the exact label used if the label property is omitted in DT, as\n>>>>>> well as use label in the example that conforms to LED device naming.\n>>>>>>\n>>>>>> @@ -69,11 +73,11 @@ Example\n>>>>>> \t\t\tflash-max-microamp = <320000>;\n>>>>>> \t\t\tled-max-microamp = <60000>;\n>>>>>> \t\t\tams,input-max-microamp = <1750000>;\n>>>>>> -\t\t\tlabel = \"as3645a:flash\";\n>>>>>> +\t\t\tlabel = \"as3645a:white:flash\";\n>>>>>> \t\t};\n>>>>>> \t\tindicator@1 {\n>>>>>> \t\t\treg = <0x1>;\n>>>>>> \t\t\tled-max-microamp = <10000>;\n>>>>>> -\t\t\tlabel = \"as3645a:indicator\";\n>>>>>> +\t\t\tlabel = \"as3645a:red:indicator\";\n>>>>>> \t\t};\n>>>>>> \t};\n>>>>>\n>>>>> Ok, but userspace still has no chance to determine if this is flash\n>>>>> from main camera or flash for front camera; todays smartphones have\n>>>>> flashes on both cameras.\n>>>>>\n>>>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n>>>>> ....?\n>>>>\n>>>> If there's just a single one in the device, could you use that?\n>>>>\n>>>> Even if we name this so for N9 (and N900), the application still would only\n>>>> work with the two devices.\n>>>\n>>> Well, I'd plan to name it on other devices, too.\n>>>\n>>>> My suggestion would be to look for a flash LED, and perhaps the maximum\n>>>> current as well. That should generally work better than assumptions on the\n>>>> label.\n>>>\n>>> If you just look for flash LED, you don't know if it is front one or\n>>> back one. Its true that if you have just one flash it is usually on\n>>> the back camera, but you can't know if maybe driver is not available\n>>> for the main flash.\n>>>\n>>> Lets get this right, please \"main_camera_flash\" is 12 bytes more than\n>>> \"flash\", and it saves application logic.. more than 12 bytes, I'm sure. \n>>\n>> What you are trying to introduce is yet another level of LED class\n>> device naming standard, one level below devicename:colour:function.\n>> It seems you want also to come up with the set of standarized LED\n>> function names. This would certainly have to be covered for consistency.\n> \n> I really dislike how this naming convention is used for label. label is \n> supposed to be the phyically identifiable name. Having the devicename \n> defeats that. Perhaps color, too. We'd be better off with a color \n> property. It seems we're overloading the naming with too many things. \n> Now we're adding device association.\n\nRegarding devicename - there is indeed inconsistency in the way how LED\nDT bindings use label, as some of them use it for defining full LED\nclass device name, and the rest fill only colour and function, leaving\naddition of a devicename to the driver.\n\nThe problem is also in current definition of label in LED common\nbindings documentation, which says:\n\n\"It has to uniquely identify a device, i.e. no other LED class device\ncan be assigned the same label.\"\n\nIn view of your above words this is not true, and we probably should\nremove this sentence (it doesn't have DT maintainer ack btw).\n\n> I do want to see standard names though. On 96boards for example, there \n> are defined LEDs and locations. The function on some are defined (e.g. \n> WiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see \n> the same label across all boards.\n\nCurrently we have following LED functions (obtained with\ngrep label Documentation/devicetree/bindings/leds/* | sed\ns'/^.*label/label/g' | awk -F\"=\" '{print $2}' | sed '/^$/d' | sed\ns'/.*:\\(.*\\)\";/\\1/' | sed '/^\\s\\{1,\\}/d' | sort -u)\n\n0\n1\n2\n2g\n3\n4\n5\n6\n7\nadsl\nalarm\nalive\naux\nbroadband\nchrg\ndsl\nflash\ngreen\nindicator\ninet\nkeypad\nphone\npower\nred\nsata\nsata0\nsata1\ntel\ntv\nupgrading\nusb\nusr0\nusr1\nusr35\nwan\nwhite\nwireless\nwps\nyellow\n\nBy extracting numerical pattern names and replacing numbers with N\nwe're getting something like this:\n\nN\nNg\ncolour\nadsl\nalarm\nalive\naux\nbroadband\nchrg\ndsl\nflash\nindicator\ninet\nkeypad\nphone\npower\nsataN\ntel\ntv\nupgrading\nusb\nusrN\nwan\nwireless\nwps\n\nIs this list something you'd like to see as a base of standard LED\nfunctions? It seems that this list would have to be continuously\nsupplemented with new positions.","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","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=\"FZerPeET\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzR0z1xFmz9t2l\n\tfor ;\n\tSat, 23 Sep 2017 07:08:51 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752477AbdIVVIu (ORCPT\n\t);\n\tFri, 22 Sep 2017 17:08:50 -0400","from mail-wr0-f177.google.com ([209.85.128.177]:49230 \"EHLO\n\tmail-wr0-f177.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752188AbdIVVIt (ORCPT\n\t); Fri, 22 Sep 2017 17:08:49 -0400","by mail-wr0-f177.google.com with SMTP id u96so1761981wrb.6;\n\tFri, 22 Sep 2017 14:08:48 -0700 (PDT)","from [192.168.1.18] (chn17.neoplus.adsl.tpnet.pl. [83.31.11.17])\n\tby smtp.gmail.com with ESMTPSA id\n\tp46sm917463wrb.46.2017.09.22.14.08.45\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 22 Sep 2017 14:08:46 -0700 (PDT)"],"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=zMxbbcXRBcTAliY6NYS7342Rz78PAQ2E981zC6OwBFc=;\n\tb=FZerPeETCZ2V+AMCk1z6i7sY6wuK44qFprx3MIiK0TwPK/U8t/n31JVcGWIeEXgvos\n\tn3DGor26flV268BfvnFc7oEMOxUAjBvvzoQhmbWQVNml4P4rKzsTpDXW4+IrOnIuZWCW\n\tl/ElqK2X5kScFIcGHmWa79icSm31+E2T6OX0vEjcX4PEnW6tpYxR6BO33UmgMjxcNeD8\n\tJCsq7P14M1O/uHz5zpdlTOkU7hYmYZec8EqXsCRecalOh1s4DwwicCaJlaRFj/uYmd7D\n\tBBaCGYkb/79Vfc5nZ1D1PBjdMNKMG4JNHGkaN5L94FglPDegNMlVMVM3ju6+VV/vO4NP\n\tFs9w==","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=zMxbbcXRBcTAliY6NYS7342Rz78PAQ2E981zC6OwBFc=;\n\tb=mB9oaGIkjq+y9MbIIFMA5v9EX7BgLiSZahUZcF3QknWUQRcQidpGjgJv/h+xxQo8cL\n\tTFPgjRdfaTn9eb+m9WnN3YkUItsqa4bYMQj6UDCEC9664UJNmTjfxEehIgXQznmnwTE8\n\tT/GAS/4zGfJhWI/5ZSOeqbIZ4yOnUL0pLx34W1HtlpLldLrI/TjNw2ie/twU9A5BtCqG\n\thPMLN2pA6HKHeKWh+BhVTbUDDQIbz/87qd9UZk3AOP/GZkMkX/rec5j4q7fW7vjIFWwZ\n\t4e71pXI+97euS6t7yvbAoC/h0x86VcOuDM3A2Swzs70ssPmkh8zzz0movX/SISEKqbs0\n\tx00g==","X-Gm-Message-State":"AHPjjUhDm5jw78WXnLoTSJkNItXakz2kzZ2O3yaMpLxSVe8KbYdQs7Fr\n\tKKsvxj8rbyiAdsii7l54WBUZfNxR","X-Google-Smtp-Source":"AOwi7QBF+43fiIPuY/tfxQfUziGsz4Ay1pc2etiglaObmSqnXGGEPtV9lrx08W923MvCaIc8QU2dQQ==","X-Received":"by 10.223.147.195 with SMTP id 61mr283870wrp.119.1506114527312; \n\tFri, 22 Sep 2017 14:08:47 -0700 (PDT)","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","To":"Rob Herring ","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>\n\t<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>\n\t<20170918205407.GA1849@amd>\n\t<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>\n\t<20170920205327.qmgz65kn45aavomx@rob-hp-laptop>","Cc":"Pavel Machek , Sakari Ailus ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<6a6651f9-b5fb-0ec7-1f40-f72b1a630e70@gmail.com>","Date":"Fri, 22 Sep 2017 23:07:53 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<20170920205327.qmgz65kn45aavomx@rob-hp-laptop>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1774084,"web_url":"http://patchwork.ozlabs.org/comment/1774084/","msgid":"<4e69932a-18af-416a-b280-16236fc4c2b3@gmail.com>","list_archive_url":null,"date":"2017-09-23T21:12:33","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 09/22/2017 11:07 PM, Jacek Anaszewski wrote:\n> On 09/20/2017 10:53 PM, Rob Herring wrote:\n>> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:\n>>> Hi Pavel,\n>>>\n>>> On 09/18/2017 10:54 PM, Pavel Machek wrote:\n>>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:\n>>>>> Hi Pavel,\n>>>>>\n>>>>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n>>>>>> Hi!\n>>>>>>\n>>>>>>> Specify the exact label used if the label property is omitted in DT, as\n>>>>>>> well as use label in the example that conforms to LED device naming.\n>>>>>>>\n>>>>>>> @@ -69,11 +73,11 @@ Example\n>>>>>>> \t\t\tflash-max-microamp = <320000>;\n>>>>>>> \t\t\tled-max-microamp = <60000>;\n>>>>>>> \t\t\tams,input-max-microamp = <1750000>;\n>>>>>>> -\t\t\tlabel = \"as3645a:flash\";\n>>>>>>> +\t\t\tlabel = \"as3645a:white:flash\";\n>>>>>>> \t\t};\n>>>>>>> \t\tindicator@1 {\n>>>>>>> \t\t\treg = <0x1>;\n>>>>>>> \t\t\tled-max-microamp = <10000>;\n>>>>>>> -\t\t\tlabel = \"as3645a:indicator\";\n>>>>>>> +\t\t\tlabel = \"as3645a:red:indicator\";\n>>>>>>> \t\t};\n>>>>>>> \t};\n>>>>>>\n>>>>>> Ok, but userspace still has no chance to determine if this is flash\n>>>>>> from main camera or flash for front camera; todays smartphones have\n>>>>>> flashes on both cameras.\n>>>>>>\n>>>>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n>>>>>> ....?\n>>>>>\n>>>>> If there's just a single one in the device, could you use that?\n>>>>>\n>>>>> Even if we name this so for N9 (and N900), the application still would only\n>>>>> work with the two devices.\n>>>>\n>>>> Well, I'd plan to name it on other devices, too.\n>>>>\n>>>>> My suggestion would be to look for a flash LED, and perhaps the maximum\n>>>>> current as well. That should generally work better than assumptions on the\n>>>>> label.\n>>>>\n>>>> If you just look for flash LED, you don't know if it is front one or\n>>>> back one. Its true that if you have just one flash it is usually on\n>>>> the back camera, but you can't know if maybe driver is not available\n>>>> for the main flash.\n>>>>\n>>>> Lets get this right, please \"main_camera_flash\" is 12 bytes more than\n>>>> \"flash\", and it saves application logic.. more than 12 bytes, I'm sure. \n>>>\n>>> What you are trying to introduce is yet another level of LED class\n>>> device naming standard, one level below devicename:colour:function.\n>>> It seems you want also to come up with the set of standarized LED\n>>> function names. This would certainly have to be covered for consistency.\n>>\n>> I really dislike how this naming convention is used for label. label is \n>> supposed to be the phyically identifiable name. Having the devicename \n>> defeats that. Perhaps color, too. We'd be better off with a color \n>> property. It seems we're overloading the naming with too many things. \n>> Now we're adding device association.\n> \n> Regarding devicename - there is indeed inconsistency in the way how LED\n> DT bindings use label, as some of them use it for defining full LED\n> class device name, and the rest fill only colour and function, leaving\n> addition of a devicename to the driver.\n> \n> The problem is also in current definition of label in LED common\n> bindings documentation, which says:\n> \n> \"It has to uniquely identify a device, i.e. no other LED class device\n> can be assigned the same label.\"\n> \n> In view of your above words this is not true, and we probably should\n> remove this sentence (it doesn't have DT maintainer ack btw).\n> \n>> I do want to see standard names though. On 96boards for example, there \n>> are defined LEDs and locations. The function on some are defined (e.g. \n>> WiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see \n>> the same label across all boards.\n> \n> Currently we have following LED functions (obtained with\n> grep label Documentation/devicetree/bindings/leds/* | sed\n> s'/^.*label/label/g' | awk -F\"=\" '{print $2}' | sed '/^$/d' | sed\n> s'/.*:\\(.*\\)\";/\\1/' | sed '/^\\s\\{1,\\}/d' | sort -u)\n> \n> 0\n> 1\n> 2\n> 2g\n> 3\n> 4\n> 5\n> 6\n> 7\n> adsl\n> alarm\n> alive\n> aux\n> broadband\n> chrg\n> dsl\n> flash\n> green\n> indicator\n> inet\n> keypad\n> phone\n> power\n> red\n> sata\n> sata0\n> sata1\n> tel\n> tv\n> upgrading\n> usb\n> usr0\n> usr1\n> usr35\n> wan\n> white\n> wireless\n> wps\n> yellow\n> \n> By extracting numerical pattern names and replacing numbers with N\n> we're getting something like this:\n> \n> N\n> Ng\n> colour\n> adsl\n> alarm\n> alive\n> aux\n> broadband\n> chrg\n> dsl\n> flash\n> indicator\n> inet\n> keypad\n> phone\n> power\n> sataN\n> tel\n> tv\n> upgrading\n> usb\n> usrN\n> wan\n> wireless\n> wps\n> \n> Is this list something you'd like to see as a base of standard LED\n> functions? It seems that this list would have to be continuously\n> supplemented with new positions.\n> \n\nEven better option is to grep through all *.dts* files in the arch\ndirectory. A slightly modified command chain. which removes numerical\npostfixes (there are some not covered corner cases though)\n\nfind arch -name \"*.dts*\" | xargs grep label | sed s'/^.*label/label/g' |\nawk -F\"=\" '{print $2}' | sed s'/.*:\\(.*\\)\";/\\1/' | sed '/^\\s\\{1,\\}/d' |\nsed s'/\\([^0-9]*\\)\\([0-9]*\\)/\\1/' | sed '/^$/d' | sort -u\n\ngives following 135 positions (~5 colours percolated due\nto some non-covered corner cases), and some of them don't belong\nto LED DT nodes unfortunately, as e.g. gpio-keys use also \":\" as\na delimiter in their labels, but the whole set gives reasonable\noverview I think:\n\nactive\nactivity_led\nadsl\nalarm\nalive\nall\namber\napp\naux\nbackup\nbackup_led\nbl\nblue\nbluetooth\nboot\nbottom\nbrick-status\nbt\nCEL\nchrg\nCOM\ncopy\ncore_module\ncpu\nD\ndebug\nDIA\ndisk\ndisk_led\ndown\ndsl\nenocean\nenter\nerr\nerror\nesata\nethernet-status\nfail\nfault\nfront\nfunc\nfunction\ng\nghz\nghz-1\nghz-2\ngpio\ngreen\ngsm\nHD\nhdd\nhdderr\nhealth\nhealth_led\nheart\nheartbeat\nhome\ninet\ninfo\ninternet\nkeypad\nL\nlan\nled\nledb\nleft\nl_hdd\nlive\nlogo\nmicroSD\nmisc\nmmc\nnand\nnetwork\non\norange\nos\npanel\npmu_stat\npower\npower_led\nprogramming\nproximitysensor\npulse\npwr\nqss\nrebuild_led\nred\nr_hdd\nright\nrouter\nrs\nrx\nsata\nsata-l\nsata-r\nsd\nSD\nsleep\nstandby\nstat\nstate\nstatus\nStatus\nsw\nsys\nsystem\nsystem-status\ntel\ntop\ntv\ntx\nup\nusb\nUSB\nusb_1\nusb_2\nusb_copy\nusb-port1\nusb-port2\nuser\nUSER\nusr\nwan\nwhite\nwifi\nwifi_ap\nwifi-status\nwireless\nwlan\nwlan_g\nwmode\nwps\nWPS\nyellow","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","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=\"eFBC1y5y\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y033z0tFYz9t5C\n\tfor ;\n\tSun, 24 Sep 2017 07:13:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750913AbdIWVNb (ORCPT\n\t);\n\tSat, 23 Sep 2017 17:13:31 -0400","from mail-wr0-f195.google.com ([209.85.128.195]:32854 \"EHLO\n\tmail-wr0-f195.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750839AbdIWVN3 (ORCPT\n\t); Sat, 23 Sep 2017 17:13:29 -0400","by mail-wr0-f195.google.com with SMTP id b9so2262193wra.0;\n\tSat, 23 Sep 2017 14:13:28 -0700 (PDT)","from [192.168.1.18] (dnq45.neoplus.adsl.tpnet.pl. [83.24.98.45])\n\tby smtp.gmail.com with ESMTPSA id\n\tm64sm3402106wmb.0.2017.09.23.14.13.25\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSat, 23 Sep 2017 14:13:26 -0700 (PDT)"],"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=MSuXidO3RIn45yPjCgWLJTOHtacgZMmUZVFomZ58K5U=;\n\tb=eFBC1y5ylG5IaiOtxG4BDa62GTZTvSzDXT+AmutmvgKQy42msK0zLOMNSbooZO6QhO\n\ti+Urdwtsm3W9msPvFuXu/hXFjYm82V9O5mmyRgM6wWvJA0B1nzVbTdcPacRSHAznjDhL\n\tSr1evQzb3/c7RjShOXNz0sISAqqVQm6/PZlBLJILHy4oQs++V1pY5VC7wpMpHjq68wIk\n\taxqqdReyAmq6Ic7ejkF/YcqJrdQpjW3JpbQfH0BfVR7K29qW0W++Hqg31n8Tk5bEvb4y\n\t6D/5rBfMQHcLW5qN4XWXyTxRFxJSHqF6aUk+go12xfgFzl8oeAizl+4xq3cb82Q2rC35\n\tJDjA==","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=MSuXidO3RIn45yPjCgWLJTOHtacgZMmUZVFomZ58K5U=;\n\tb=pfh4Z4QGdISZuIr19Zx066x3aPGGyNj0QvS8xygvBMZMkUMCs2AhwMEutvgGdDr/GS\n\tgZ4wSDfLM9cKmowC3Z9oNuxtOiC/Y43qEr8Z368J2qtDS9mSiS/a4H111oHLcrQFeceO\n\tf8pexudsZDAtXYfy01hXjuG4Nja6qULLGkd3I3lp+4IUtlwgAMQLrDYf/XVRbt326rSC\n\tOL4idJKdq/WhyTkIRDwW2VoUKfr5TQiJgOq8qe7MBzh5fQmN/rOkg4nXbelF83KH/QaR\n\tfORcuIzhB8ddY7o9vk0kMaXI1pbcy91rcRxl2SiIcjTDkrdRuertt+vuLxOaYEH1vrZ3\n\trzog==","X-Gm-Message-State":"AHPjjUiKphGsHGilfqffiwZo2Z5Vca6F62woKixWafpxPtaCEcvfBE1E\n\tV43DjHL5rdNzt394hNH3/1vk14Rj","X-Google-Smtp-Source":"AOwi7QAX6hv4PLWq2xpf3U5iuSqQU9kPSq9ljZvK/SQ23uSPKcaiZyr481lIaJXRSJQcQ7HOo2/dfA==","X-Received":"by 10.223.139.157 with SMTP id o29mr2596133wra.190.1506201207544;\n\tSat, 23 Sep 2017 14:13:27 -0700 (PDT)","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","To":"Rob Herring ","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>\n\t<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>\n\t<20170918205407.GA1849@amd>\n\t<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>\n\t<20170920205327.qmgz65kn45aavomx@rob-hp-laptop>\n\t<6a6651f9-b5fb-0ec7-1f40-f72b1a630e70@gmail.com>","Cc":"Pavel Machek , Sakari Ailus ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"<4e69932a-18af-416a-b280-16236fc4c2b3@gmail.com>","Date":"Sat, 23 Sep 2017 23:12:33 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<6a6651f9-b5fb-0ec7-1f40-f72b1a630e70@gmail.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1806841,"web_url":"http://patchwork.ozlabs.org/comment/1806841/","msgid":"","list_archive_url":null,"date":"2017-11-18T13:38:07","subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"Hi Rob,\n\nAny thoughts on my analysis? Do you think that LED function naming\nstandardization would really make sense having the abundance\nof LED functions categories present in the mainline dts files?\n\nThe list of standard LED function names would have to be\ncontinuously extended as people would be adding new boards.\nLimiting users to only existing set of LED functions wouldn't\nbe practical IMHO.\n\nI'd propose only to modify 'label' property description in LED common\nbindings, so that it would explicitly state that it should contain only\n\"colour:functon\" segments. It would be driver's responsibility to add\n\"devicename:\" prefix to the label and use the whole string for a LED\nclass device name. Some drivers do that already. All DT bindings, dts\nfiles and LED class drivers that don't adhere to this rule would have\nto be updated accordingly.\n\nRegarding colour - the \"devicename:colour:function\" LED device naming\nconvention defined in Documentation/leds/leds-class.txt is around for\na long time. Since LED colour can vary from board two board and is\nindependent of a driver, we have to have a means for defining it in\nDT. Would you see providing separate 'colour' DT property as a solution?\n\nBest regards,\nJacek Anaszewski\n\nOn 09/23/2017 11:12 PM, Jacek Anaszewski wrote:\n> On 09/22/2017 11:07 PM, Jacek Anaszewski wrote:\n>> On 09/20/2017 10:53 PM, Rob Herring wrote:\n>>> On Tue, Sep 19, 2017 at 11:01:02PM +0200, Jacek Anaszewski wrote:\n>>>> Hi Pavel,\n>>>>\n>>>> On 09/18/2017 10:54 PM, Pavel Machek wrote:\n>>>>> On Mon 2017-09-18 17:49:23, Sakari Ailus wrote:\n>>>>>> Hi Pavel,\n>>>>>>\n>>>>>> On Mon, Sep 18, 2017 at 12:56:55PM +0200, Pavel Machek wrote:\n>>>>>>> Hi!\n>>>>>>>\n>>>>>>>> Specify the exact label used if the label property is omitted in DT, as\n>>>>>>>> well as use label in the example that conforms to LED device naming.\n>>>>>>>>\n>>>>>>>> @@ -69,11 +73,11 @@ Example\n>>>>>>>> \t\t\tflash-max-microamp = <320000>;\n>>>>>>>> \t\t\tled-max-microamp = <60000>;\n>>>>>>>> \t\t\tams,input-max-microamp = <1750000>;\n>>>>>>>> -\t\t\tlabel = \"as3645a:flash\";\n>>>>>>>> +\t\t\tlabel = \"as3645a:white:flash\";\n>>>>>>>> \t\t};\n>>>>>>>> \t\tindicator@1 {\n>>>>>>>> \t\t\treg = <0x1>;\n>>>>>>>> \t\t\tled-max-microamp = <10000>;\n>>>>>>>> -\t\t\tlabel = \"as3645a:indicator\";\n>>>>>>>> +\t\t\tlabel = \"as3645a:red:indicator\";\n>>>>>>>> \t\t};\n>>>>>>>> \t};\n>>>>>>>\n>>>>>>> Ok, but userspace still has no chance to determine if this is flash\n>>>>>>> from main camera or flash for front camera; todays smartphones have\n>>>>>>> flashes on both cameras.\n>>>>>>>\n>>>>>>> So.. Can I suggset as3645a:white:main_camera_flash or main_flash or\n>>>>>>> ....?\n>>>>>>\n>>>>>> If there's just a single one in the device, could you use that?\n>>>>>>\n>>>>>> Even if we name this so for N9 (and N900), the application still would only\n>>>>>> work with the two devices.\n>>>>>\n>>>>> Well, I'd plan to name it on other devices, too.\n>>>>>\n>>>>>> My suggestion would be to look for a flash LED, and perhaps the maximum\n>>>>>> current as well. That should generally work better than assumptions on the\n>>>>>> label.\n>>>>>\n>>>>> If you just look for flash LED, you don't know if it is front one or\n>>>>> back one. Its true that if you have just one flash it is usually on\n>>>>> the back camera, but you can't know if maybe driver is not available\n>>>>> for the main flash.\n>>>>>\n>>>>> Lets get this right, please \"main_camera_flash\" is 12 bytes more than\n>>>>> \"flash\", and it saves application logic.. more than 12 bytes, I'm sure. \n>>>>\n>>>> What you are trying to introduce is yet another level of LED class\n>>>> device naming standard, one level below devicename:colour:function.\n>>>> It seems you want also to come up with the set of standarized LED\n>>>> function names. This would certainly have to be covered for consistency.\n>>>\n>>> I really dislike how this naming convention is used for label. label is \n>>> supposed to be the phyically identifiable name. Having the devicename \n>>> defeats that. Perhaps color, too. We'd be better off with a color \n>>> property. It seems we're overloading the naming with too many things. \n>>> Now we're adding device association.\n>>\n>> Regarding devicename - there is indeed inconsistency in the way how LED\n>> DT bindings use label, as some of them use it for defining full LED\n>> class device name, and the rest fill only colour and function, leaving\n>> addition of a devicename to the driver.\n>>\n>> The problem is also in current definition of label in LED common\n>> bindings documentation, which says:\n>>\n>> \"It has to uniquely identify a device, i.e. no other LED class device\n>> can be assigned the same label.\"\n>>\n>> In view of your above words this is not true, and we probably should\n>> remove this sentence (it doesn't have DT maintainer ack btw).\n>>\n>>> I do want to see standard names though. On 96boards for example, there \n>>> are defined LEDs and locations. The function on some are defined (e.g. \n>>> WiFi/BT) and somewhat undefined on others (user{1-4}). I'd like to see \n>>> the same label across all boards.\n>>\n>> Currently we have following LED functions (obtained with\n>> grep label Documentation/devicetree/bindings/leds/* | sed\n>> s'/^.*label/label/g' | awk -F\"=\" '{print $2}' | sed '/^$/d' | sed\n>> s'/.*:\\(.*\\)\";/\\1/' | sed '/^\\s\\{1,\\}/d' | sort -u)\n>>\n>> 0\n>> 1\n>> 2\n>> 2g\n>> 3\n>> 4\n>> 5\n>> 6\n>> 7\n>> adsl\n>> alarm\n>> alive\n>> aux\n>> broadband\n>> chrg\n>> dsl\n>> flash\n>> green\n>> indicator\n>> inet\n>> keypad\n>> phone\n>> power\n>> red\n>> sata\n>> sata0\n>> sata1\n>> tel\n>> tv\n>> upgrading\n>> usb\n>> usr0\n>> usr1\n>> usr35\n>> wan\n>> white\n>> wireless\n>> wps\n>> yellow\n>>\n>> By extracting numerical pattern names and replacing numbers with N\n>> we're getting something like this:\n>>\n>> N\n>> Ng\n>> colour\n>> adsl\n>> alarm\n>> alive\n>> aux\n>> broadband\n>> chrg\n>> dsl\n>> flash\n>> indicator\n>> inet\n>> keypad\n>> phone\n>> power\n>> sataN\n>> tel\n>> tv\n>> upgrading\n>> usb\n>> usrN\n>> wan\n>> wireless\n>> wps\n>>\n>> Is this list something you'd like to see as a base of standard LED\n>> functions? It seems that this list would have to be continuously\n>> supplemented with new positions.\n>>\n> \n> Even better option is to grep through all *.dts* files in the arch\n> directory. A slightly modified command chain. which removes numerical\n> postfixes (there are some not covered corner cases though)\n> \n> find arch -name \"*.dts*\" | xargs grep label | sed s'/^.*label/label/g' |\n> awk -F\"=\" '{print $2}' | sed s'/.*:\\(.*\\)\";/\\1/' | sed '/^\\s\\{1,\\}/d' |\n> sed s'/\\([^0-9]*\\)\\([0-9]*\\)/\\1/' | sed '/^$/d' | sort -u\n> \n> gives following 135 positions (~5 colours percolated due\n> to some non-covered corner cases), and some of them don't belong\n> to LED DT nodes unfortunately, as e.g. gpio-keys use also \":\" as\n> a delimiter in their labels, but the whole set gives reasonable\n> overview I think:\n> \n> active\n> activity_led\n> adsl\n> alarm\n> alive\n> all\n> amber\n> app\n> aux\n> backup\n> backup_led\n> bl\n> blue\n> bluetooth\n> boot\n> bottom\n> brick-status\n> bt\n> CEL\n> chrg\n> COM\n> copy\n> core_module\n> cpu\n> D\n> debug\n> DIA\n> disk\n> disk_led\n> down\n> dsl\n> enocean\n> enter\n> err\n> error\n> esata\n> ethernet-status\n> fail\n> fault\n> front\n> func\n> function\n> g\n> ghz\n> ghz-1\n> ghz-2\n> gpio\n> green\n> gsm\n> HD\n> hdd\n> hdderr\n> health\n> health_led\n> heart\n> heartbeat\n> home\n> inet\n> info\n> internet\n> keypad\n> L\n> lan\n> led\n> ledb\n> left\n> l_hdd\n> live\n> logo\n> microSD\n> misc\n> mmc\n> nand\n> network\n> on\n> orange\n> os\n> panel\n> pmu_stat\n> power\n> power_led\n> programming\n> proximitysensor\n> pulse\n> pwr\n> qss\n> rebuild_led\n> red\n> r_hdd\n> right\n> router\n> rs\n> rx\n> sata\n> sata-l\n> sata-r\n> sd\n> SD\n> sleep\n> standby\n> stat\n> state\n> status\n> Status\n> sw\n> sys\n> system\n> system-status\n> tel\n> top\n> tv\n> tx\n> up\n> usb\n> USB\n> usb_1\n> usb_2\n> usb_copy\n> usb-port1\n> usb-port2\n> user\n> USER\n> usr\n> wan\n> white\n> wifi\n> wifi_ap\n> wifi-status\n> wireless\n> wlan\n> wlan_g\n> wmode\n> wps\n> WPS\n> yellow\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","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","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=\"ruNZMNPk\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yfGL41HXMz9ryQ\n\tfor ;\n\tSun, 19 Nov 2017 00:39:24 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S935758AbdKRNjK (ORCPT );\n\tSat, 18 Nov 2017 08:39:10 -0500","from mail-wr0-f194.google.com ([209.85.128.194]:35824 \"EHLO\n\tmail-wr0-f194.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S935754AbdKRNjI (ORCPT\n\t); Sat, 18 Nov 2017 08:39:08 -0500","by mail-wr0-f194.google.com with SMTP id w95so4356212wrc.2;\n\tSat, 18 Nov 2017 05:39:07 -0800 (PST)","from [192.168.1.18] (bkp183.neoplus.adsl.tpnet.pl. [83.28.183.183])\n\tby smtp.gmail.com with ESMTPSA id\n\tx75sm8678405wme.29.2017.11.18.05.39.04\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tSat, 18 Nov 2017 05:39:05 -0800 (PST)"],"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=9leGJGPaWd5z1BqutsZiVi6KZ7lfSUUFqJvzSWCyX7E=;\n\tb=ruNZMNPkK5YGMbXTRXIesDN+AMOQYjB9Sy/wB0u03YWT7JU+8NoqLNuBX3Zv6UHACp\n\tdLSQJBR05+O06hilMrUGsDqi/LjLiyluDvpayO3LI5KyK1TZt17rIQDDZwVb2yrCrKR6\n\t0gea+51DtLCh95S7i81bts+EzYNdlsqXLEgSuiGthYLG7l0oazJFBvzinmN1raGUB0vz\n\tq9B4ZsKiMJqRI2djMEy/otA0PNFNz7ySm+duNE05n+2EWtsMcy1FYv/JsrpS0ZH7NZu2\n\tcSth+WA3S5vMeWcfiOzNGhGyZbftIxYfgXo5eeF7J+OfnMCuoTC59wJeS9qQFXuZ3FAx\n\tETZQ==","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=9leGJGPaWd5z1BqutsZiVi6KZ7lfSUUFqJvzSWCyX7E=;\n\tb=LRe/4lA38zliG/72RiYVs95pud4Yqnb2cU7Qa2JU1qzWAuCFUwLbo+knfygs1Jy5Qc\n\tCf0O21MWX5qvsurfwugdMOE0roqx+CiDj6syDRlbur3wkafL3n8xcesTZX0Fh1uY8DWz\n\t7KsGr/pvSAriUm9Yh2KPY/em6iSCEXSvdQFvmYIygQKHpnPK2dEGapMgt6a90ufsPfr7\n\tcldepCvn7wND4ia9SJ/gDqDUsudVk68XHX2mgfMxo6HDCPPSmtGOqR969j+coMOl5WyZ\n\tMxpfTeZLGcG8/q7ARY714R6n/ZAPIG0BK8vOYGihy2MPzueINT5gNUj49pI8jJHyAJCr\n\tAfEw==","X-Gm-Message-State":"AJaThX5ULUk1Jvm9ENJcmqNy0ZRdfidSVMkkQ4ehLdq7uE6gF9TiXiiG\n\teHwQ/2qb8YD5VazlxDJoeRwxIml7","X-Google-Smtp-Source":"AGs4zMb2CeymwXMQZQq7p5huroZc+N5B3ixe1OTxGgoCReWq3v6q2EWQT+UeQe1k58Ymi6zaPrFppw==","X-Received":"by 10.223.197.131 with SMTP id m3mr7572023wrg.0.1511012346782;\n\tSat, 18 Nov 2017 05:39:06 -0800 (PST)","Subject":"Re: [RESEND PATCH v2 4/6] dt: bindings: as3645a: Improve label\n\tdocumentation, DT example","To":"Rob Herring ","References":"<20170918102349.8935-1-sakari.ailus@linux.intel.com>\n\t<20170918102349.8935-5-sakari.ailus@linux.intel.com>\n\t<20170918105655.GA14591@amd>\n\t<20170918144923.dnhrxkirle3fvdfo@valkosipuli.retiisi.org.uk>\n\t<20170918205407.GA1849@amd>\n\t<809f7590-7641-e8bc-c009-4fed05d5827c@gmail.com>\n\t<20170920205327.qmgz65kn45aavomx@rob-hp-laptop>\n\t<6a6651f9-b5fb-0ec7-1f40-f72b1a630e70@gmail.com>\n\t<4e69932a-18af-416a-b280-16236fc4c2b3@gmail.com>","Cc":"Pavel Machek , Sakari Ailus ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tdevicetree@vger.kernel.org,\n\t\"linux-kernel@vger.kernel.org\" ,\n\tDan Murphy ","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1110","Message-ID":"","Date":"Sat, 18 Nov 2017 14:38:07 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.8.0","MIME-Version":"1.0","In-Reply-To":"<4e69932a-18af-416a-b280-16236fc4c2b3@gmail.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"8bit","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]