[{"id":2330416,"web_url":"http://patchwork.ozlabs.org/comment/2330416/","msgid":"<20191221193758.GJ32732@amd>","list_archive_url":null,"date":"2019-12-21T19:37:58","subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support to\n\tLED class/core","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> Qucik grep for 'for_each' or 'linux,default-trigger' or\n\nquick.\n\n> If init_data is goven but no starting point for node lookup - then\n\nis given.\n\n> (parent) device's own DT node is used. If no led-compatible is given,\n> then of_match is searched for. If neither led-compatible not of_match\n\nnor of_match.\n\n> is given then device's own node or passed starting point are used as\n> such.\n> \n> Signed-off-by: Matti Vaittinen \n> ---\n> \n> No changes since v6\n> \n> drivers/leds/led-class.c | 99 +++++++++++++--\n> drivers/leds/led-core.c | 258 ++++++++++++++++++++++++++++++++-------\n> include/linux/leds.h | 94 ++++++++++++--\n> 3 files changed, 385 insertions(+), 66 deletions(-)\n\nQuite a lot of code added here. Can I trust you that we we'll delete\n320 lines by converting driver or two?\n\n> +static void led_add_props(struct led_classdev *ld, struct led_properties *props)\n> +{\n> +\tif (props->default_trigger)\n> +\t\tld->default_trigger = props->default_trigger;\n> +\t/*\n> +\t * According to binding docs the LED is by-default turned OFF unless\n> +\t * default_state is used to indicate it should be ON or that state\n> +\t * should be kept as is\n> +\t */\n> +\tif (props->default_state) {\n> +\t\tld->brightness = LED_OFF;\n> +\t\tif (!strcmp(props->default_state, \"on\"))\n> +\t\t\tld->brightness = LED_FULL;\n\nMax brightness is not always == LED_FULL these days.\n\n> @@ -322,6 +398,10 @@ int led_classdev_register_ext(struct device *parent,\n> \t\t\tled_cdev->name);\n> \n> \treturn 0;\n> +err_out:\n> +\tif (led_cdev->fwnode_owned)\n> +\t\tfwnode_handle_put(fw);\n> +\treturn ret;\n> }\n\nled_cdev->fwnode_owned = false here?\n\n\n> +/**\n> + * led_find_fwnode - find fwnode for led\n> + * @parent\tLED controller device\n> + * @init_data\tled init data with match information\n> + *\n> + * Scans the firmware nodes and returns node matching the given init_data.\n> + * NOTE: Function increases refcount for found node. Caller must decrease\n> + * refcount using fwnode_handle_put when finished with node.\n> + */\n> +struct fwnode_handle *led_find_fwnode(struct device *parent,\n> +\t\t\t\t struct led_init_data *init_data)\n> +{\n> +\tstruct fwnode_handle *fw;\n> +\n> +\t/*\n> +\t * This should never be called W/O init data. We could always return\n\nwithout\n\n> +\t * For now we do only do node look-up for drivers which populate\n> +\t * the new match properties. We could and perhaps should do\n> +\t * fw = dev_fwnode(parent); if given fwnode is NULL. But in order to\n> +\t * not break existing setups we keep the old behaviour and just directly\n\nnot to break.\n\n> +\t/*\n> +\t * Simple things are pretty. I think simplest is to use DT node-name\n> +\t * for matching the node with LED - same way regulators use the node\n> +\t * name to match with desc.\n> +\t *\n> +\t * This may not work with existing LED DT entries if the node name has\n> +\t * been freely selectible. In order to this to work the binding doc\n\nselectable?\n\n> +\t/**\n> +\t * Please note, logic changed - if invalid property is found we bail\n> +\t * early out without parsing the rest of the properties. Originally\n> +\t * this was the case only for 'label' property. I don't know the\n> +\t * rationale behind original logic allowing invalid properties to be\n> +\t * given. If there is a reason then we should reconsider this.\n> +\t * Intuitively it feels correct to just yell and quit if we hit value we\n> +\t * don't understand - but intuition may be wrong at times :)\n> +\t */\n\nIs this supposed to be linuxdoc?\n\n> +/**\n> + * led_find_fwnode - find fwnode matching given LED init data\n> + * @parent: LED controller device this LED is driven by\n> + * @init_data: the LED class device initialization data\n> + *\n> + * Find the fw node matching given LED init data.\n> + * NOTE: Function increases refcount for found node. Caller must decrease\n> + * refcount using fwnode_handle_put when finished with node.\n> + *\n> + * Returns: node handle or NULL if matching fw node was not found\n> + */\n> +struct fwnode_handle *led_find_fwnode(struct device *parent,\n> +\t\t\t\t struct led_init_data *init_data);\n> +\n\nIf function _gets_ the node and increments its usage count, is it\nnormally called \"get\"?\n\nBest regards,\n\t\t\t\t\t\t\t\tPavel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (no SPF record)\n\tsmtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67;\n\thelo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdmarc=none (p=none dis=none) header.from=ucw.cz"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 47gG9l4f4vz9sP3\n\tfor ;\n\tSun, 22 Dec 2019 06:38:03 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1726976AbfLUTiD (ORCPT );\n\tSat, 21 Dec 2019 14:38:03 -0500","from jabberwock.ucw.cz ([46.255.230.98]:44320 \"EHLO\n\tjabberwock.ucw.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1726567AbfLUTiC (ORCPT\n\t); Sat, 21 Dec 2019 14:38:02 -0500","by jabberwock.ucw.cz (Postfix, from userid 1017)\n\tid A25F51C24A9; Sat, 21 Dec 2019 20:37:59 +0100 (CET)"],"Date":"Sat, 21 Dec 2019 20:37:58 +0100","From":"Pavel Machek ","To":"Matti Vaittinen ","Cc":"mazziesaccount@gmail.com, Jacek Anaszewski ,\n\tDan Murphy , Rob Herring ,\n\tMark Rutland , Lee Jones ,\n\tMichael Turquette ,\n\tStephen Boyd ,\n\tLinus Walleij ,\n\tBartosz Golaszewski ,\n\tLiam Girdwood , Mark Brown ,\n\tAlessandro Zummo ,\n\tAlexandre Belloni ,\n\tlinux-leds@vger.kernel.org, devicetree@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,\n\tlinux-gpio@vger.kernel.org, linux-rtc@vger.kernel.org","Subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support to\n\tLED class/core","Message-ID":"<20191221193758.GJ32732@amd>","References":"\n\t","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"vkEkAx9hr54EJ73W\"","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":2330871,"web_url":"http://patchwork.ozlabs.org/comment/2330871/","msgid":"","list_archive_url":null,"date":"2019-12-23T10:35:51","subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","submitter":{"id":74146,"url":"http://patchwork.ozlabs.org/api/people/74146/","name":"Matti Vaittinen","email":"matti.vaittinen@fi.rohmeurope.com"},"content":"Hello Pavel,\n\nOn Sat, 2019-12-21 at 20:37 +0100, Pavel Machek wrote:\n> Hi!\n> \n> > Qucik grep for 'for_each' or 'linux,default-trigger' or\n> \n> quick.\n> \n> > If init_data is goven but no starting point for node lookup - then\n> \n> is given.\n> \n> > (parent) device's own DT node is used. If no led-compatible is\n> > given,\n> > then of_match is searched for. If neither led-compatible not\n> > of_match\n> \n> nor of_match.\n> \n> > is given then device's own node or passed starting point are used\n> > as\n> > such.\n> > \n> > Signed-off-by: Matti Vaittinen \n> > ---\n> > \n> > No changes since v6\n> > \n> > drivers/leds/led-class.c | 99 +++++++++++++--\n> > drivers/leds/led-core.c | 258 ++++++++++++++++++++++++++++++++---\n> > ----\n> > include/linux/leds.h | 94 ++++++++++++--\n> > 3 files changed, 385 insertions(+), 66 deletions(-)\n> \n> Quite a lot of code added here. Can I trust you that we we'll delete\n> 320 lines by converting driver or two?\n\nI believe we do. Besides bunch of the lines are comments. I don't think\nI actually added much of new things here. And one thing we should not\noverlook is the drivers to come. I believe amount of LED devices we\nwill be getting drivers for will increase. 320 lines is peanuts if we\nget 5 new drivers all implementing the same DT parsing loop.\n\nAnyways, I will look all of the comments thoroughly during next Friday.\nI am currently having a vacation and I might get strangled by my family\nif I spend it staring at the computer xD\n\nThanks for taking the time to look at this! I do appreciate the effort!\n\nBr,\n\tMatti Vaittinen","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (no SPF record)\n\tsmtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67;\n\thelo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dmarc=none (p=none dis=none)\n\theader.from=fi.rohmeurope.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 47hG3Z4yNFz9sR1\n\tfor ;\n\tMon, 23 Dec 2019 21:36:10 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1726832AbfLWKgG (ORCPT );\n\tMon, 23 Dec 2019 05:36:06 -0500","from mailgate1.rohmeurope.com ([178.15.145.194]:53894 \"EHLO\n\tmailgate1.rohmeurope.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1726150AbfLWKgG (ORCPT\n\t); Mon, 23 Dec 2019 05:36:06 -0500","from smtp.reu.rohmeu.com (will-cas002.reu.rohmeu.com\n\t[192.168.251.178])\n\tby mailgate1.rohmeurope.com (Symantec Messaging Gateway) with SMTP id\n\t48.78.08102.398900E5; Mon, 23 Dec 2019 11:36:03 +0100 (CET)","from WILL-MAIL001.REu.RohmEu.com ([fe80::2915:304f:d22c:c6ba]) by\n\tWILL-CAS002.REu.RohmEu.com ([fe80::fc24:4cbc:e287:8659%12]) with\n\tmapi id 14.03.0439.000; Mon, 23 Dec 2019 11:35:51 +0100"],"X-AuditID":"c0a8fbf4-183ff70000001fa6-f0-5e009893a6a7","From":"\"Vaittinen, Matti\" ","To":"\"pavel@ucw.cz\" ","CC":"\"linux-leds@vger.kernel.org\" ,\n\t\"dmurphy@ti.com\" ,\n\t\"linux-rtc@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"alexandre.belloni@bootlin.com\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"mturquette@baylibre.com\" ,\n\t\"mazziesaccount@gmail.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"jacek.anaszewski@gmail.com\" ,\n\t\"a.zummo@towertech.it\" ,\n\t\"linus.walleij@linaro.org\" ,\n\t\"lgirdwood@gmail.com\" ,\n\t\"mark.rutland@arm.com\" ,\n\t\"robh+dt@kernel.org\" ,\n\t\"bgolaszewski@baylibre.com\" ,\n\t\"linux-clk@vger.kernel.org\" ,\n\t\"lee.jones@linaro.org\" ,\n\t\"sboyd@kernel.org\" ,\n\t\"broonie@kernel.org\" ","Subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Topic":"[PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Index":"AQHVtlJMyatI9ieot0i0jk0Qmtw3YKfE7uMAgAKNQAA=","Date":"Mon, 23 Dec 2019 10:35:51 +0000","Message-ID":"","References":"\n\t\n\t<20191221193758.GJ32732@amd>","In-Reply-To":"<20191221193758.GJ32732@amd>","Accept-Language":"en-US, de-DE","Content-Language":"de-DE","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[82.203.188.194]","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA02Te0gUURjFuzOzs1drYtw0b9uDHHrQy5KMLiFR0GOC6EEIIeU25uRauisz\n\ta1hSSCW1JmVUZIuuZlpharVluWmPNbds7SWlFdlDEkuLJDKlLG1mp9J/Zs7c8/3OmYFvIGlo\n\tpY0w0WITJYuQxNGB1O1zfa5ZR3OHxc45dXcmLm5s0uP9X87ocXe+j8LHW9toXFD3SIcPNlzR\n\t4VeVFyn89rsX4J5nBwh87NdZAn/NfqPDlwt+Afz0eh6NKz9XAHz3/DMalzxvJHBeST2FG31L\n\t8Wufl8aZN+r0uL/5ErUohC9zlgG+60WmnneWpfNux2s97yq103xLcw3N33txjeBPOH8Q/Lnz\n\tvXr+m2vCmsCY4VFxgm37usQEy+yFm4abPZkxKS1BadWePl0GKAzKAgEQsZHI+/kBmQUCoYFt\n\tAuhWz6G/D/UADeT6qCwAIc1GoayXehUIZsPQ5Ww7rc6Q7FWI3O1NhDozio1F185O0mZMqOJj\n\tAaHpBSi/q8gfQ7GTUce7Zapk2FWoYv96rekOQM7sNv94ADsN3XG3+KsAOx7ZM774z0k2FLna\n\te3XaO7OouOYxqekQ1PG+X6dmIpZDNwciVUkqMReuz9bkIuSuMmohYejYwVZ/OMMGofsn26gc\n\tMNoxJN8xCDsGYccQ2DEELgS6UoCShcSkBMEmRoRLYmq4ZDUnK7fN1mQX0JaluwoM1K6oBQQE\n\ttWAMJLgQhlsyLNYwMs4av8MsyGaTlJokyrUAQZILZqp3/d5oYOKFHTtFyfrPGgspLpSZ2npk\n\to4FVu7aJYooo/XPHQcghJu2EEhokiQli2pbEJNugTcAANTzQGCyLlnhRElJtZpO6GSZZWQ3V\n\tGqH0HlFxRk4RkpVTDfWBCJjTkV9Ewrr8EuWac7TrNGmgLFaLaAxl5qoAqwLmVMv/uk4QCgE3\n\tipmnuiOU/+Z/WqdSRChFD8f3Kx8o24RBy5gBFnSXi1s7PUUR375+aonyVs03Rds9OWRae2TV\n\tWtqT/qS5ptf9YfHbyac/Oqr3pe9p3At326yHV+yTtl8omvFg4KcMY35XVhDLnWvzttrbN/Ty\n\tfZ6esIsNxQnZE6I355aejDZPqo+eNuPS05UPG8oXR3rdDEl3H189pXhX+PS4ibico2SzEDGd\n\tlGThD86Ow1b0AwAA","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":2332023,"web_url":"http://patchwork.ozlabs.org/comment/2332023/","msgid":"","list_archive_url":null,"date":"2019-12-27T11:29:34","subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","submitter":{"id":74146,"url":"http://patchwork.ozlabs.org/api/people/74146/","name":"Matti Vaittinen","email":"matti.vaittinen@fi.rohmeurope.com"},"content":"On Sat, 2019-12-21 at 20:37 +0100, Pavel Machek wrote:\n> Hi!\n> \n> > Qucik grep for 'for_each' or 'linux,default-trigger' or\n> \n> quick.\n> \n> > If init_data is goven but no starting point for node lookup - then\n> \n> is given.\n> \n> > (parent) device's own DT node is used. If no led-compatible is\n> > given,\n> > then of_match is searched for. If neither led-compatible not\n> > of_match\n> \n> nor of_match.\n> \n> > is given then device's own node or passed starting point are used\n> > as\n> > such.\n> > \n> > Signed-off-by: Matti Vaittinen \n> > ---\n> > \n> > No changes since v6\n> > \n> > drivers/leds/led-class.c | 99 +++++++++++++--\n> > drivers/leds/led-core.c | 258 ++++++++++++++++++++++++++++++++---\n> > ----\n> > include/linux/leds.h | 94 ++++++++++++--\n> > 3 files changed, 385 insertions(+), 66 deletions(-)\n> \n> Quite a lot of code added here. Can I trust you that we we'll delete\n> 320 lines by converting driver or two?\n> \n> > +static void led_add_props(struct led_classdev *ld, struct\n> > led_properties *props)\n> > +{\n> > +\tif (props->default_trigger)\n> > +\t\tld->default_trigger = props->default_trigger;\n> > +\t/*\n> > +\t * According to binding docs the LED is by-default turned OFF\n> > unless\n> > +\t * default_state is used to indicate it should be ON or that\n> > state\n> > +\t * should be kept as is\n> > +\t */\n> > +\tif (props->default_state) {\n> > +\t\tld->brightness = LED_OFF;\n> > +\t\tif (!strcmp(props->default_state, \"on\"))\n> > +\t\t\tld->brightness = LED_FULL;\n> \n> Max brightness is not always == LED_FULL these days.\n\nHmm. That sounds like having LED_FULL is pretty pointless then, right?\nI mean, if LED_FULL may not be LED_FULL, why we have LED_FULL then?\nAnyways, I don't know what would be better value for the default state\n\"on\"? I am willing to rework the patch here but I need some guidance.\nOther option is to use the LED_FULL here and leave drivers using\nsomething else to use own property parsing - or convert them to use\nLED_FULL too. (Sorry, I don't know these drivers or why they don't use\nLED_FULL so I can't say if this makes sense or not). Can you give me a\nnudge as how to improve this?\n\n> \n> > @@ -322,6 +398,10 @@ int led_classdev_register_ext(struct device\n> > *parent,\n> > \t\t\tled_cdev->name);\n> > \n> > \treturn 0;\n> > +err_out:\n> > +\tif (led_cdev->fwnode_owned)\n> > +\t\tfwnode_handle_put(fw);\n> > +\treturn ret;\n> > }\n> \n> led_cdev->fwnode_owned = false here?\n\nHmm. Thanks. I didn't think that the cdev is not freed here and could\nbe re-used. So yes. I think we could set the led_cdev->fwnode_owned to\nfalse here. I'll fix this. Good catch :)\n\n> \n> \n> > +/**\n> > + * led_find_fwnode - find fwnode for led\n> > + * @parent\tLED controller device\n> > + * @init_data\tled init data with match information\n> > + *\n> > + * Scans the firmware nodes and returns node matching the given\n> > init_data.\n> > + * NOTE: Function increases refcount for found node. Caller must\n> > decrease\n> > + * refcount using fwnode_handle_put when finished with node.\n> > + */\n> > +struct fwnode_handle *led_find_fwnode(struct device *parent,\n> > +\t\t\t\t struct led_init_data *init_data)\n> > +{\n> > +\tstruct fwnode_handle *fw;\n> > +\n> > +\t/*\n> > +\t * This should never be called W/O init data. We could always\n> > return\n> \n> without\n\nRight.\n\n> > +\t * For now we do only do node look-up for drivers which\n> > populate\n> > +\t * the new match properties. We could and perhaps should do\n> > +\t * fw = dev_fwnode(parent); if given fwnode is NULL. But in\n> > order to\n> > +\t * not break existing setups we keep the old behaviour and just\n> > directly\n> \n> not to break.\n\nIndeed, thanks!\n\n> > +\t/*\n> > +\t * Simple things are pretty. I think simplest is to use DT\n> > node-name\n> > +\t * for matching the node with LED - same way regulators use the\n> > node\n> > +\t * name to match with desc.\n> > +\t *\n> > +\t * This may not work with existing LED DT entries if the node\n> > name has\n> > +\t * been freely selectible. In order to this to work the binding\n> > doc\n> \n> selectable?\n\nAh. Again the same problem I had with regulator voltage ranges support.\nEnglish is hard. Google told me that selectible or selectable are not\nreally good words to use - hence I ended up using 'pickable' ranges. I\nthink this could also be \"if the node name has been freely pickable.\nI'll switch to that.\n\n> > +\t/**\n> > +\t * Please note, logic changed - if invalid property is found we\n> > bail\n> > +\t * early out without parsing the rest of the properties.\n> > Originally\n> > +\t * this was the case only for 'label' property. I don't know\n> > the\n> > +\t * rationale behind original logic allowing invalid properties\n> > to be\n> > +\t * given. If there is a reason then we should reconsider this.\n> > +\t * Intuitively it feels correct to just yell and quit if we hit\n> > value we\n> > +\t * don't understand - but intuition may be wrong at times :)\n> > +\t */\n> \n> Is this supposed to be linuxdoc?\n\ndefinitely not. Thanks! I'll remove the extra *\n\n> \n> > +/**\n> > + * led_find_fwnode - find fwnode matching given LED init data\n> > + * @parent: LED controller device this LED is driven by\n> > + * @init_data: the LED class device initialization data\n> > + *\n> > + * Find the fw node matching given LED init data.\n> > + * NOTE: Function increases refcount for found node. Caller must\n> > decrease\n> > + * refcount using fwnode_handle_put when finished with node.\n> > + *\n> > + * Returns: node handle or NULL if matching fw node was not found\n> > + */\n> > +struct fwnode_handle *led_find_fwnode(struct device *parent,\n> > +\t\t\t\t struct led_init_data *init_data);\n> > +\n> \n> If function _gets_ the node and increments its usage count, is it\n> normally called \"get\"?\n\nOk, thanks for the guidance. I didn't know that. I'll change this to\nled_get_fwnode :)\n\nThanks a bunch!\n\nBr,\n\tMatti Vaittinen","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (no SPF record)\n\tsmtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67;\n\thelo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dmarc=none (p=none dis=none)\n\theader.from=fi.rohmeurope.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 47kl3c6mQpz9sPn\n\tfor ;\n\tFri, 27 Dec 2019 22:29:48 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1726675AbfL0L3o (ORCPT );\n\tFri, 27 Dec 2019 06:29:44 -0500","from mailgate1.rohmeurope.com ([178.15.145.194]:55800 \"EHLO\n\tmailgate1.rohmeurope.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1726053AbfL0L3n (ORCPT\n\t); Fri, 27 Dec 2019 06:29:43 -0500","from smtp.reu.rohmeu.com (will-cas001.reu.rohmeu.com\n\t[192.168.251.177])\n\tby mailgate1.rohmeurope.com (Symantec Messaging Gateway) with SMTP id\n\tE1.E8.08102.42BE50E5; Fri, 27 Dec 2019 12:29:40 +0100 (CET)","from WILL-MAIL001.REu.RohmEu.com ([fe80::2915:304f:d22c:c6ba]) by\n\tWILL-CAS001.REu.RohmEu.com ([fe80::d57e:33d0:7a5d:f0a6%16]) with\n\tmapi id 14.03.0439.000; Fri, 27 Dec 2019 12:29:35 +0100"],"X-AuditID":"c0a8fbf4-199ff70000001fa6-c0-5e05eb24ad1a","From":"\"Vaittinen, Matti\" ","To":"\"pavel@ucw.cz\" ","CC":"\"linux-leds@vger.kernel.org\" ,\n\t\"dmurphy@ti.com\" ,\n\t\"linux-rtc@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"alexandre.belloni@bootlin.com\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"mturquette@baylibre.com\" ,\n\t\"mazziesaccount@gmail.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"jacek.anaszewski@gmail.com\" ,\n\t\"a.zummo@towertech.it\" ,\n\t\"linus.walleij@linaro.org\" ,\n\t\"lgirdwood@gmail.com\" ,\n\t\"mark.rutland@arm.com\" ,\n\t\"robh+dt@kernel.org\" ,\n\t\"bgolaszewski@baylibre.com\" ,\n\t\"linux-clk@vger.kernel.org\" ,\n\t\"lee.jones@linaro.org\" ,\n\t\"sboyd@kernel.org\" ,\n\t\"broonie@kernel.org\" ","Subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Topic":"[PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Index":"AQHVtlJMyatI9ieot0i0jk0Qmtw3YKfE7uMAgAjliYA=","Date":"Fri, 27 Dec 2019 11:29:34 +0000","Message-ID":"","References":"\n\t\n\t<20191221193758.GJ32732@amd>","In-Reply-To":"<20191221193758.GJ32732@amd>","Accept-Language":"en-US, de-DE","Content-Language":"de-DE","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[213.255.186.46]","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"<7191390565294940BE4674ED4008C769@de.rohmeurope.com>","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA02Tf0wTZxjH895dr2/RI2cF+8p00ZtOnfHXwvTVGKyJmOMfXKZ/mM1RTznb\n\tRmjZtRCd/zAzN4HG4ESXdtAataPhh9oiVhQTU2EgJBoUEH8wZHZk4CJxKkpGdPf2pvDPe988\n\t3+fzfJ8/noO0cYRNg3aHW1YcUp7AJjHXQv+Gly18ostZ2bYan+nq0eMfn/6qxy+qOhh8fDDO\n\t4kDLTR0u67ygww8azzN44GUrwGPdhylcMVFN4Wee33W4ITAB8J3LlSxu/PsswL/VdrM4eLeL\n\twpXBdgZ3dWTi/o5WFh+62qLHb3rDjDlVrPPXAXG075Be9NcdEJt8/XoxUlPCig97m1mxrS9K\n\tiT/7xykxVPtKLz6PfPh50pfT1u+S3EVb7VbHioyd02ydzbsLPOZ949d+YYvBpYxSYICIT0d/\n\tPooxpSAJGvkegMJvn+uJYeTbAYoc21oKIGT59aj0XqKcws9HDZ4SlvTT/EWImoZ6KNIzk89B\n\t0eoFWo8Fnf0rQGl6Haof7qaJZviF6Hv/KR3RHJ+NwlHSQ3KvA+T3xBOAgV+Crjc9TIQBfi4q\n\tKX6aqNO8CUWGXum0pXl0pvkWrelUNPz4zf91AV0dH2TIPrQ659zlFRpqRv90lrGano8qygb1\n\t2g4z0A1vnCkHs3xTEnyTtG8K7ZtC+6bQJ4GuBqB8yZ5nldzyquWKXLhccdry1c9uZ34EaPfy\n\t4hJ4G8uKAQqCGJgNKSGVux3U5RiTdzlz99skl82iFObJrhhAkBZSOIdV9bhcaf+3suJ8Z30A\n\tGcHELRo8+rWRJ1l7ZblAVt65cyAUEBccUcEZimyV9+2x57knbQoayPCktBSX7MiVFanQbbOQ\n\t67C41PMg1nQ1FxKccxVI+WpVQzvAGlg+XHWKhg1VQfVtSbzlx0ZP00bG4XTIaSbOTjCeYLZC\n\tx/vQEWCCQJjJzSHudPUHej9zRI2j1LhnRorEuaVJK60Y+DfO/jRL/iMaflLDZm5+MLByx+IT\n\tFyaSvzBsad5gZjKHxirmjd333v9oz+11R3sDH/f+FPLWW08md9/I8H62aeMOtDq9EWffPBg9\n\tuPZW1pW5yw5HvjFt2yy08aH4eJGlrnxtdiDk3b709Q+eI32pwlfpL887x7zxrL5WQ9Hr9kff\n\tmR8LjMsmrfqEVlzSf7eMbCP9AwAA","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":2332033,"web_url":"http://patchwork.ozlabs.org/comment/2332033/","msgid":"<4f5c3d6b5e10936b3bae672021aec375c2880bf2.camel@fi.rohmeurope.com>","list_archive_url":null,"date":"2019-12-27T11:51:07","subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","submitter":{"id":74146,"url":"http://patchwork.ozlabs.org/api/people/74146/","name":"Matti Vaittinen","email":"matti.vaittinen@fi.rohmeurope.com"},"content":"On Sat, 2019-12-21 at 20:37 +0100, Pavel Machek wrote:\n> Hi!\n> \n> > Qucik grep for 'for_each' or 'linux,default-trigger' or\n> \n> quick.\n> \n> > If init_data is goven but no starting point for node lookup - then\n> \n> is given.\n> \n> > (parent) device's own DT node is used. If no led-compatible is\n> > given,\n> > then of_match is searched for. If neither led-compatible not\n> > of_match\n> \n> nor of_match.\n> \n> > is given then device's own node or passed starting point are used\n> > as\n> > such.\n> > \n> > Signed-off-by: Matti Vaittinen \n> > ---\n> > \n\n//snip\n\n> > @@ -322,6 +398,10 @@ int led_classdev_register_ext(struct device\n> > *parent,\n> > \t\t\tled_cdev->name);\n> > \n> > \treturn 0;\n> > +err_out:\n> > +\tif (led_cdev->fwnode_owned)\n> > +\t\tfwnode_handle_put(fw);\n> > +\treturn ret;\n> > }\n> \n> led_cdev->fwnode_owned = false here?\n\nI added this although with the current patch it should not be required.\nThe led_cdev->fwnode_owned is anyways re-initialized at the beginning\nof the 'led_classdev_register_ext'. It won't eat many cycles to zero it\nhere though so perhaps it's safer to just do it.\n\nI am not sure I can finish and test the patch v7 today. So it may be\nnext year when I am able to send it... Sorry for the delay!\n\n\nBr,\n\tMatti Vaittinen","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (no SPF record)\n\tsmtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67;\n\thelo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dmarc=none (p=none dis=none)\n\theader.from=fi.rohmeurope.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 47klXT2XDmz9sPK\n\tfor ;\n\tFri, 27 Dec 2019 22:51:21 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1726562AbfL0LvQ (ORCPT );\n\tFri, 27 Dec 2019 06:51:16 -0500","from mailgate1.rohmeurope.com ([178.15.145.194]:56324 \"EHLO\n\tmailgate1.rohmeurope.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1726053AbfL0LvQ (ORCPT\n\t); Fri, 27 Dec 2019 06:51:16 -0500","from smtp.reu.rohmeu.com (will-cas002.reu.rohmeu.com\n\t[192.168.251.178])\n\tby mailgate1.rohmeurope.com (Symantec Messaging Gateway) with SMTP id\n\t90.F8.08102.130F50E5; Fri, 27 Dec 2019 12:51:13 +0100 (CET)","from WILL-MAIL001.REu.RohmEu.com ([fe80::2915:304f:d22c:c6ba]) by\n\tWILL-CAS002.REu.RohmEu.com ([fe80::fc24:4cbc:e287:8659%12]) with\n\tmapi id 14.03.0439.000; Fri, 27 Dec 2019 12:51:08 +0100"],"X-AuditID":"c0a8fbf4-199ff70000001fa6-2e-5e05f03118ce","From":"\"Vaittinen, Matti\" ","To":"\"pavel@ucw.cz\" ","CC":"\"linux-leds@vger.kernel.org\" ,\n\t\"dmurphy@ti.com\" ,\n\t\"linux-rtc@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"alexandre.belloni@bootlin.com\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"mturquette@baylibre.com\" ,\n\t\"mazziesaccount@gmail.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"jacek.anaszewski@gmail.com\" ,\n\t\"a.zummo@towertech.it\" ,\n\t\"linus.walleij@linaro.org\" ,\n\t\"lgirdwood@gmail.com\" ,\n\t\"mark.rutland@arm.com\" ,\n\t\"robh+dt@kernel.org\" ,\n\t\"bgolaszewski@baylibre.com\" ,\n\t\"linux-clk@vger.kernel.org\" ,\n\t\"lee.jones@linaro.org\" ,\n\t\"sboyd@kernel.org\" ,\n\t\"broonie@kernel.org\" ","Subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Topic":"[PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Index":"AQHVtlJMyatI9ieot0i0jk0Qmtw3YKfE7uMAgAjrkIA=","Date":"Fri, 27 Dec 2019 11:51:07 +0000","Message-ID":"<4f5c3d6b5e10936b3bae672021aec375c2880bf2.camel@fi.rohmeurope.com>","References":"\n\t\n\t<20191221193758.GJ32732@amd>","In-Reply-To":"<20191221193758.GJ32732@amd>","Accept-Language":"en-US, de-DE","Content-Language":"de-DE","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[213.255.186.46]","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"<35D7AE440FBBEF4692D77DA8C8D1C20F@de.rohmeurope.com>","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA02Ta0wTWRTHc2emM7fowFhed+sjUjVm1yxKQuJdl6gflIxGjYkaEqN0Bxhb\n\tIp3itBjdJYomPlqQYHyFhhajIqgEtMpiiW4QwQXWFyKoEVSEKBAXMSBqxMdMR4VPc+b8/7/z\n\tPx/OhaThGW2E6ZJTlCUhw0SHULVlH/2/xg3qkuf1dfyGT7W0MXjfwGkGD3ubKXykq4fGxfW3\n\tdTj3v0s6/LjqPIWfvm0AeOT+fgIfHi0l8Ju8Jzp8sXgU4NaaIhpXvaoA+Ma5+zQuedBC4KKS\n\tRgq3NC/Fnc0NNN5ztZ7Bn9svUIsj+XJfOeBfP9zD8L7yv/iAp5Ph/WddNN/RfoXm/31YTfDH\n\tfB8IvuzcO4Yf8k9bHbJ+QkKK4Ny6Jt0izV34xwTrLXcvlVkWuu3u00oqB7xn3UAPEReP8ttP\n\tUm4QAg1cG0C9TaWM9tMI0K6XhYoCIc0lIPcjRgUiuBh0Mc9Fqx6S+xuiwIs2QvWEc8mounSm\n\t5jGjit5iQqsXoKZbd4MWipuFjnrXqm2WW4UqCw8SWtR1gHx5PUG/nvsZXQ90BLMANxW5cgaC\n\tfZKLRv4X73Ta0hw6deUOqdWRqK/787e+CV390BVcmVTmVNbM1dDF6PlgDdDqGHQ4t4vRdpiE\n\tmgp7qAIQ5RmX4BmjPeNozzjaM44+DnRnAbIJ6RkWwSnGxcpiVqxst9qUT6rd5gfaxQxfBl/q\n\tltUBAoI68BMkTJHsvRJdsiE0xZ623So4rGY5K0N01AEESVMEK1kUjU0Ttv8pyvbv0mRImaLZ\n\t2V0HNxo4NWuzKGaK8nd1CoQmxDpeK+AkWbSI2zalZzjHZALq1eEhxgiHKKWJspDltJrV8zA7\n\tlPtQpYlK7kIVZx2Zgk3pamgzmAML+rwnSFjvLTlBGijJLonGaHa6auVUqzVL+hHUD6IhMIWz\n\tn/5X1InKs/kxp1+JIJSINwZCjXAKY5IxB+x9+7t++fIRy6qk6uczhPhrW6MoGLbrZuz8hmWZ\n\tN7a0hl3ObnQNDWcL7opB8okxsPbjy8TUbH+VfI/IExOiksJz9ZSUvzLM3DN6ZtAf+0/K7oii\n\tfG+ifVO2r3DdY3rBtc5ZO2rnxM/bMPvQ0EBijM01ElgUtT90b/fO1iUHOpL6V5goh1WI+4WU\n\tHcJX+zfP7PMDAAA=","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}},{"id":2332657,"web_url":"http://patchwork.ozlabs.org/comment/2332657/","msgid":"<8359b8365f6c86fe4acb9c35c2c6be55091b45a3.camel@fi.rohmeurope.com>","list_archive_url":null,"date":"2019-12-30T07:36:17","subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","submitter":{"id":74146,"url":"http://patchwork.ozlabs.org/api/people/74146/","name":"Matti Vaittinen","email":"matti.vaittinen@fi.rohmeurope.com"},"content":"Hello Again Pavel,\n\nOn Sat, 2019-12-21 at 20:37 +0100, Pavel Machek wrote:\n> > +static void led_add_props(struct led_classdev *ld, struct\n> > led_properties *props)\n> > +{\n> > +\tif (props->default_trigger)\n> > +\t\tld->default_trigger = props->default_trigger;\n> > +\t/*\n> > +\t * According to binding docs the LED is by-default turned OFF\n> > unless\n> > +\t * default_state is used to indicate it should be ON or that\n> > state\n> > +\t * should be kept as is\n> > +\t */\n> > +\tif (props->default_state) {\n> > +\t\tld->brightness = LED_OFF;\n> > +\t\tif (!strcmp(props->default_state, \"on\"))\n> > +\t\t\tld->brightness = LED_FULL;\n> \n> Max brightness is not always == LED_FULL these days.\n\nI took another look at this and changed this to:\n\nif (!strcmp(props->default_state, \"on\")) {\n\tif (!ld->max_brightness)\n\t\tld->brightness = LED_FULL;\n\telse\n\t\tld->brightness = ld->max_brightness;\n}\n\nI hope this is what you were suggesting. I'll send the v8 (hopefully)\nsoon(ish).\n\nBest Regards\n\tMatti","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (no SPF record)\n\tsmtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67;\n\thelo=vger.kernel.org;\n\tenvelope-from=linux-gpio-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dmarc=none (p=none dis=none)\n\theader.from=fi.rohmeurope.com"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 47mTl7015Xz9sPc\n\tfor ;\n\tMon, 30 Dec 2019 18:36:34 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1727244AbfL3Hgd (ORCPT );\n\tMon, 30 Dec 2019 02:36:33 -0500","from mailgate1.rohmeurope.com ([178.15.145.194]:62412 \"EHLO\n\tmailgate1.rohmeurope.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1727173AbfL3Hgd (ORCPT\n\t); Mon, 30 Dec 2019 02:36:33 -0500","from smtp.reu.rohmeu.com (will-cas002.reu.rohmeu.com\n\t[192.168.251.178])\n\tby mailgate1.rohmeurope.com (Symantec Messaging Gateway) with SMTP id\n\t28.83.08102.EF8A90E5; Mon, 30 Dec 2019 08:36:30 +0100 (CET)","from WILL-MAIL001.REu.RohmEu.com ([fe80::2915:304f:d22c:c6ba]) by\n\tWILL-CAS002.REu.RohmEu.com ([fe80::fc24:4cbc:e287:8659%12]) with\n\tmapi id 14.03.0439.000; Mon, 30 Dec 2019 08:36:19 +0100"],"X-AuditID":"c0a8fbf4-199ff70000001fa6-38-5e09a8fedbab","From":"\"Vaittinen, Matti\" ","To":"\"pavel@ucw.cz\" ","CC":"\"linux-leds@vger.kernel.org\" ,\n\t\"dmurphy@ti.com\" ,\n\t\"linux-rtc@vger.kernel.org\" ,\n\t\"linux-gpio@vger.kernel.org\" ,\n\t\"alexandre.belloni@bootlin.com\" ,\n\t\"linux-kernel@vger.kernel.org\" ,\n\t\"mturquette@baylibre.com\" ,\n\t\"mazziesaccount@gmail.com\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"jacek.anaszewski@gmail.com\" ,\n\t\"a.zummo@towertech.it\" ,\n\t\"linus.walleij@linaro.org\" ,\n\t\"lgirdwood@gmail.com\" ,\n\t\"mark.rutland@arm.com\" ,\n\t\"robh+dt@kernel.org\" ,\n\t\"bgolaszewski@baylibre.com\" ,\n\t\"linux-clk@vger.kernel.org\" ,\n\t\"lee.jones@linaro.org\" ,\n\t\"sboyd@kernel.org\" ,\n\t\"broonie@kernel.org\" ","Subject":"Re: [PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Topic":"[PATCH v7 11/12] leds: Add common LED binding parsing support\n\tto LED class/core","Thread-Index":"AQHVtlJMyatI9ieot0i0jk0Qmtw3YKfE7uMAgA1bZYA=","Date":"Mon, 30 Dec 2019 07:36:17 +0000","Message-ID":"<8359b8365f6c86fe4acb9c35c2c6be55091b45a3.camel@fi.rohmeurope.com>","References":"\n\t\n\t<20191221193758.GJ32732@amd>","In-Reply-To":"<20191221193758.GJ32732@amd>","Accept-Language":"en-US, de-DE","Content-Language":"de-DE","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[213.255.186.46]","Content-Type":"text/plain; charset=\"utf-8\"","Content-ID":"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-Brightmail-Tracker":"H4sIAAAAAAAAA02Ta0wTWRTH986rt8VZhwpyrfgaH/iIiBvjXg1ZNdFklPiIJn4wWBxllhL7\n\tINNiQN2EfRAE2YhGRSoPo7xEAlpEpZGEFHDdEtcQRXxCGhtUsmHDiiKRrTvTUeHTPfec/+/8\n\tz4dzIGkMMCaYbndJsl208oyBaqv96FkeqtWbEy718biyu0eH84aqdXikzE/hM4Eggys6/qLx\n\t8a7rNH7WfJXC/e86AX7/8BiBT4/XEHi4sI/GTRXjAD/wljK4+e8GgO9cecjgqt5uApdW3aVw\n\tt38TfuHvZHBua4cOhx5do9ZHC/Xl9UD453GuTiivPyK0uF/oBE9dPiM8f3SbEf54fJMQisvH\n\tCKH2yqhOeOuZvcOwJyJxv+g6tCs9zb7ih30RlluXjzEZQUNW28ApOge0GQqAHiJuFaoeOUsU\n\tAAM0cj0ABWu9jPa5C1Dd8CXlAyHDJaKCJzoViOLmoabC/LCG5G5A1DLQQ6iaaZwZ3axZoGlS\n\tUMPrCkKL16Lm9l5ajSluIQoWd4X7sNw21Dh+j9a82gEqLwyGAT23BLW3PA+LADcL5ecMhfMk\n\tF4M8A6O0NjWHKm/fJ7U4Gr15Gfqc51HrWIBS5yGVPo3eFRq6Hp37eZDW4nno9PHA5xki0Z8l\n\tQaoITHdPcnBP0O5JtHsS7Z5EXwB0HUA2Md2aJrqklfGylBkvOyw25TngsHmAtjIjt8An32Yf\n\tICDwgRmQ4KPZihPQbPx2vyM12yI6LSlyplVy+gCCJB/FrkrWm41sqph9WJIdX0ozIcXHsHGB\n\tk3uNnOp1UJIyJPlLNRZCHrG2agWMlKU0KevHdKtrokxAvdrcYIpySvZUSRYzXZYUdT9SnMqC\n\tqKUpii+j4qwzQ7QpWQ31g2Ww6E3ZRRJ2lFVdJI2U3WGXTDGst0aRcqrUkmn/ajQIYiDgp7Gt\n\tyoEYpyh387XPoGJBKBZbIKNauMSJkikHSP/O2ChGjrhCv+3ezmctjN0QUZjUlDQat3h136He\n\t6LiE8wd3bl36U3zay5C35l2pU0ye2bimv/j+kH95zyKU2FX0a/v2BPm/DZ3Ws/MTXv/ecCpH\n\tyi1Oih1L/nTv1YV1eZGzj8aNbcs7+d0vWZWXP8wp+GZB6vc7S/qfTs/wTR1eYjZlz+Upp0Vc\n\tuZSUneL/+jCsR/QDAAA=","Sender":"linux-gpio-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-gpio@vger.kernel.org"}}]