[{"id":1766822,"web_url":"http://patchwork.ozlabs.org/comment/1766822/","msgid":"","list_archive_url":null,"date":"2017-09-12T09:38:27","subject":"Re: [PATCH v11 13/24] v4l: async: Allow async notifier register call\n\tsucceed with no subdevs","submitter":{"id":723,"url":"http://patchwork.ozlabs.org/api/people/723/","name":"Hans Verkuil","email":"hverkuil@xs4all.nl"},"content":"On 09/12/17 10:42, Sakari Ailus wrote:\n> The information on how many async sub-devices would be bindable to a\n> notifier is typically dependent on information from platform firmware and\n> it's not driver's business to be aware of that.\n> \n> Many V4L2 main drivers are perfectly usable (and useful) without async\n> sub-devices and so if there aren't any around, just proceed call the\n> notifier's complete callback immediately without registering the notifier\n> itself.\n> \n> If a driver needs to check whether there are async sub-devices available,\n> it can be done by inspecting the notifier's num_subdevs field which tells\n> the number of async sub-devices.\n> \n> Signed-off-by: Sakari Ailus \n\nAcked-by: Hans Verkuil \n\nRegards,\n\n\tHans\n\n> ---\n> drivers/media/v4l2-core/v4l2-async.c | 6 ++++--\n> 1 file changed, 4 insertions(+), 2 deletions(-)\n> \n> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c\n> index 7b396ff4302b..4525b03d59c1 100644\n> --- a/drivers/media/v4l2-core/v4l2-async.c\n> +++ b/drivers/media/v4l2-core/v4l2-async.c\n> @@ -170,14 +170,16 @@ int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,\n> \tstruct v4l2_async_subdev *asd;\n> \tint i;\n> \n> -\tif (!v4l2_dev || !notifier->num_subdevs ||\n> -\t notifier->num_subdevs > V4L2_MAX_SUBDEVS)\n> +\tif (!v4l2_dev || notifier->num_subdevs > V4L2_MAX_SUBDEVS)\n> \t\treturn -EINVAL;\n> \n> \tnotifier->v4l2_dev = v4l2_dev;\n> \tINIT_LIST_HEAD(¬ifier->waiting);\n> \tINIT_LIST_HEAD(¬ifier->done);\n> \n> +\tif (!notifier->num_subdevs)\n> +\t\treturn v4l2_async_notifier_call_complete(notifier);\n> +\n> \tfor (i = 0; i < notifier->num_subdevs; i++) {\n> \t\tasd = notifier->subdevs[i];\n> \n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","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 3xs0981h7pz9sNV\n\tfor ;\n\tTue, 12 Sep 2017 19:38:36 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751286AbdILJie (ORCPT\n\t);\n\tTue, 12 Sep 2017 05:38:34 -0400","from lb1-smtp-cloud8.xs4all.net ([194.109.24.21]:41995 \"EHLO\n\tlb1-smtp-cloud8.xs4all.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751326AbdILJie (ORCPT\n\t); Tue, 12 Sep 2017 05:38:34 -0400","from [IPv6:2001:420:44c1:2579:b8de:7eb8:366e:7de6]\n\t([IPv6:2001:420:44c1:2579:b8de:7eb8:366e:7de6])\n\tby smtp-cloud8.xs4all.net with ESMTPA\n\tid rheGdorVQcQyLrheKdtJVV; Tue, 12 Sep 2017 11:38:32 +0200"],"Subject":"Re: [PATCH v11 13/24] v4l: async: Allow async notifier register call\n\tsucceed with no subdevs","To":"Sakari Ailus , linux-media@vger.kernel.org","Cc":"niklas.soderlund@ragnatech.se, robh@kernel.org,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tpavel@ucw.cz, sre@kernel.org","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-14-sakari.ailus@linux.intel.com>","From":"Hans Verkuil ","Message-ID":"","Date":"Tue, 12 Sep 2017 11:38:27 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170912084236.1154-14-sakari.ailus@linux.intel.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-CMAE-Envelope":"MS4wfGNwtFIoSULxXOMmV96QLmjXDOBVIGd/5lFWbkuh10lKGlFbo4LeGy3Vx0v6IkAuMpusFTkVYuIGLGje9K2/JNyuQnw8p8Swj6X6gq2Sta/jna7qc/9I\n\tS1lK0IkSkTHsH8HSV75le66+E15M6lnJQBA4NuW72XwWY8yY6kYvUc5qhkQYKGZ+l+hBLPAF+gq9nKO0U6gSEOKPdvlrIPoGOF+DQdIrCJXBN3CIR75NKzNk\n\tqeGrRlNRW5EmTJ20V0WKbX0Lphw4Quwp3DuNQZ2glZtpNt1A1B7IvVQpEob0jJeyFimJkI45mU8//hJVJXwl/GJl75hvL9nAa/fnGBlyStKMrxjNhwzxF1aC\n\twq9vgeP+Db3U45ktEep+gnvWL/qSAJR151KeaH0moKMzw7e5yDJ1+yJWGTYeTJXp/a4LXy8cJL/Wcm+rOsH8FeD2KR17AlMllxCVF70ntIIahUS7ajroOIjh\n\tkvRbrt4iPgNhjlXj9FzXBhEdPSeMxiPUeQSxnWWu1GwMXqWjlbK3JmLrU8M3vzKdW79+/HK+F1b1+8WgE4gd6AH1hZM6fpor5kwP2APmx+h8nU4L3peOjOVp\n\tpj8=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1766823,"web_url":"http://patchwork.ozlabs.org/comment/1766823/","msgid":"","list_archive_url":null,"date":"2017-09-12T09:39:32","subject":"Re: [PATCH v11 11/24] v4l: async: Introduce helpers for calling\n\tasync ops callbacks","submitter":{"id":723,"url":"http://patchwork.ozlabs.org/api/people/723/","name":"Hans Verkuil","email":"hverkuil@xs4all.nl"},"content":"On 09/12/17 10:42, Sakari Ailus wrote:\n> Add three helper functions to call async operations callbacks. Besides\n> simplifying callbacks, this allows async notifiers to have no ops set,\n> i.e. it can be left NULL.\n> \n> Signed-off-by: Sakari Ailus \n\nI'm sure I acked this already, but in case it was lost:\n\nAcked-by: Hans Verkuil \n\nRegards,\n\n\tHans\n\n> ---\n> drivers/media/v4l2-core/v4l2-async.c | 49 ++++++++++++++++++++++++++----------\n> include/media/v4l2-async.h | 1 +\n> 2 files changed, 37 insertions(+), 13 deletions(-)\n> \n> diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c\n> index a2df85ea00f4..c34f93593b41 100644\n> --- a/drivers/media/v4l2-core/v4l2-async.c\n> +++ b/drivers/media/v4l2-core/v4l2-async.c\n> @@ -25,6 +25,34 @@\n> #include \n> #include \n> \n> +static int v4l2_async_notifier_call_bound(struct v4l2_async_notifier *n,\n> +\t\t\t\t\t struct v4l2_subdev *subdev,\n> +\t\t\t\t\t struct v4l2_async_subdev *asd)\n> +{\n> +\tif (!n->ops || !n->ops->bound)\n> +\t\treturn 0;\n> +\n> +\treturn n->ops->bound(n, subdev, asd);\n> +}\n> +\n> +static void v4l2_async_notifier_call_unbind(struct v4l2_async_notifier *n,\n> +\t\t\t\t\t struct v4l2_subdev *subdev,\n> +\t\t\t\t\t struct v4l2_async_subdev *asd)\n> +{\n> +\tif (!n->ops || !n->ops->unbind)\n> +\t\treturn;\n> +\n> +\tn->ops->unbind(n, subdev, asd);\n> +}\n> +\n> +static int v4l2_async_notifier_call_complete(struct v4l2_async_notifier *n)\n> +{\n> +\tif (!n->ops || !n->ops->complete)\n> +\t\treturn 0;\n> +\n> +\treturn n->ops->complete(n);\n> +}\n> +\n> static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)\n> {\n> #if IS_ENABLED(CONFIG_I2C)\n> @@ -102,16 +130,13 @@ static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,\n> {\n> \tint ret;\n> \n> -\tif (notifier->ops->bound) {\n> -\t\tret = notifier->ops->bound(notifier, sd, asd);\n> -\t\tif (ret < 0)\n> -\t\t\treturn ret;\n> -\t}\n> +\tret = v4l2_async_notifier_call_bound(notifier, sd, asd);\n> +\tif (ret < 0)\n> +\t\treturn ret;\n> \n> \tret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);\n> \tif (ret < 0) {\n> -\t\tif (notifier->ops->unbind)\n> -\t\t\tnotifier->ops->unbind(notifier, sd, asd);\n> +\t\tv4l2_async_notifier_call_unbind(notifier, sd, asd);\n> \t\treturn ret;\n> \t}\n> \n> @@ -123,8 +148,8 @@ static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,\n> \t/* Move from the global subdevice list to notifier's done */\n> \tlist_move(&sd->async_list, ¬ifier->done);\n> \n> -\tif (list_empty(¬ifier->waiting) && notifier->ops->complete)\n> -\t\treturn notifier->ops->complete(notifier);\n> +\tif (list_empty(¬ifier->waiting))\n> +\t\treturn v4l2_async_notifier_call_complete(notifier);\n> \n> \treturn 0;\n> }\n> @@ -210,8 +235,7 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)\n> \tlist_for_each_entry_safe(sd, tmp, ¬ifier->done, async_list) {\n> \t\tv4l2_async_cleanup(sd);\n> \n> -\t\tif (notifier->ops->unbind)\n> -\t\t\tnotifier->ops->unbind(notifier, sd, sd->asd);\n> +\t\tv4l2_async_notifier_call_unbind(notifier, sd, sd->asd);\n> \t}\n> \n> \tmutex_unlock(&list_lock);\n> @@ -300,8 +324,7 @@ void v4l2_async_unregister_subdev(struct v4l2_subdev *sd)\n> \n> \tv4l2_async_cleanup(sd);\n> \n> -\tif (notifier->ops->unbind)\n> -\t\tnotifier->ops->unbind(notifier, sd, sd->asd);\n> +\tv4l2_async_notifier_call_unbind(notifier, sd, sd->asd);\n> \n> \tmutex_unlock(&list_lock);\n> }\n> diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h\n> index 3c48f8b66d12..3bc8a7c0d83f 100644\n> --- a/include/media/v4l2-async.h\n> +++ b/include/media/v4l2-async.h\n> @@ -164,4 +164,5 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd);\n> * @sd: pointer to &struct v4l2_subdev\n> */\n> void v4l2_async_unregister_subdev(struct v4l2_subdev *sd);\n> +\n> #endif\n> \n\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","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 3xs0BL42LJz9sNV\n\tfor ;\n\tTue, 12 Sep 2017 19:39:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751326AbdILJjh (ORCPT\n\t);\n\tTue, 12 Sep 2017 05:39:37 -0400","from lb1-smtp-cloud8.xs4all.net ([194.109.24.21]:52263 \"EHLO\n\tlb1-smtp-cloud8.xs4all.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751286AbdILJjg (ORCPT\n\t); Tue, 12 Sep 2017 05:39:36 -0400","from [IPv6:2001:420:44c1:2579:b8de:7eb8:366e:7de6]\n\t([IPv6:2001:420:44c1:2579:b8de:7eb8:366e:7de6])\n\tby smtp-cloud8.xs4all.net with ESMTPA\n\tid rhfIdosINcQyLrhfLdtJsA; Tue, 12 Sep 2017 11:39:35 +0200"],"Subject":"Re: [PATCH v11 11/24] v4l: async: Introduce helpers for calling\n\tasync ops callbacks","To":"Sakari Ailus , linux-media@vger.kernel.org","Cc":"niklas.soderlund@ragnatech.se, robh@kernel.org,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tpavel@ucw.cz, sre@kernel.org","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-12-sakari.ailus@linux.intel.com>","From":"Hans Verkuil ","Message-ID":"","Date":"Tue, 12 Sep 2017 11:39:32 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170912084236.1154-12-sakari.ailus@linux.intel.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-CMAE-Envelope":"MS4wfKGeRS8BpW7i3QV81ETQTQlHKgqhPeYKm9biYonoycuRVbF/kLpcKCgClxy9p1zJseXWirctF+gdIUXcyWcn5RGuF/sJKPO8C2CWkgshSfe9QG0XYaDe\n\t5ItLXP2su0b6JkLNoz2g8vXQ5NA2MBf2ThmpwK2DAI4cNuaS1BMyhIVeFv9q7FVGc8fAQ4y7F/wnAUdpBvJRx8GzRWpiFKNHTIcMr9esd+QIedKU5mXzHZau\n\tPHKq5/Vr0UnMgiC0PNaf0HZd/PAiI5akf0Xjqd85wraixkZS4bveip7Xvm+5nR4LEuLRE1BuiJcyoDjlSaG9gB+Rn+WVZGV2Il59r+hoNDCAOxRB51+TUQ2U\n\tiEB/UP5f6q1rZvWDrF1g2tphXkT/V0QeHVH+ou1dWI2DoJbslYy3lJ8yfOS7AqTgQ645JyFO1xXzOC8QI+C8Sve2rOsY9ct5eaeuE5hNVYrD4NDdrQcKLUFh\n\tW9yTaOtpZJvn1sttMq0dg8CgFbaw1aHY6uKASYpBNBzVUKUVVj1aLlDjF3Ks0Xe1PeIs6nrzXI/mI2hPxWx+/NYKo0r5WBZEVVUfL2CCGKtHV1RpKu2YZb8j\n\tey4=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1766853,"web_url":"http://patchwork.ozlabs.org/comment/1766853/","msgid":"<20170912103143.GA27117@amd>","list_archive_url":null,"date":"2017-09-12T10:31:43","subject":"Re: [PATCH v11 21/24] smiapp: Add support for flash and lens devices","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"On Tue 2017-09-12 11:42:33, Sakari Ailus wrote:\n> Parse async sub-devices by using\n> v4l2_subdev_fwnode_reference_parse_sensor_common().\n> \n> These types devices aren't directly related to the sensor, but are\n> nevertheless handled by the smiapp driver due to the relationship of these\n> component to the main part of the camera module --- the sensor.\n> \n> This does not yet address providing the user space with information on how\n> to associate the sensor or lens devices but the kernel now has the\n> necessary information to do that.\n> \n> Signed-off-by: Sakari Ailus \n> Acked-by: Hans Verkuil \n\nAcked-by: Pavel Machek ","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 3xs1LW5pdsz9s7g\n\tfor ;\n\tTue, 12 Sep 2017 20:31:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751289AbdILKbq (ORCPT\n\t);\n\tTue, 12 Sep 2017 06:31:46 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:44340 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751424AbdILKbp (ORCPT\n\t); Tue, 12 Sep 2017 06:31:45 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid 3533F824EE; Tue, 12 Sep 2017 12:31:44 +0200 (CEST)"],"Date":"Tue, 12 Sep 2017 12:31:43 +0200","From":"Pavel Machek ","To":"Sakari Ailus ","Cc":"linux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: [PATCH v11 21/24] smiapp: Add support for flash and lens devices","Message-ID":"<20170912103143.GA27117@amd>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-22-sakari.ailus@linux.intel.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"0F1p//8PRICkK4MW\"","Content-Disposition":"inline","In-Reply-To":"<20170912084236.1154-22-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":1766855,"web_url":"http://patchwork.ozlabs.org/comment/1766855/","msgid":"<20170912103628.GB27117@amd>","list_archive_url":null,"date":"2017-09-12T10:36:28","subject":"as3645a flash userland interface ","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\nThere were some changes to as3645a flash controller. Before we have\nstable interface we have to keep forever I want to ask:\n\nWhat directory are the flash controls in?\n\n/sys/class/leds/led-controller:flash ?\n\nCould we arrange for something less generic, like\n\n/sys/class/leds/main-camera:flash ?\n\nThanks,\n\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 3xs1S06rpZz9sNV\n\tfor ;\n\tTue, 12 Sep 2017 20:36:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751418AbdILKgb (ORCPT\n\t);\n\tTue, 12 Sep 2017 06:36:31 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:44473 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751289AbdILKga (ORCPT\n\t); Tue, 12 Sep 2017 06:36:30 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid 35593824F6; Tue, 12 Sep 2017 12:36:29 +0200 (CEST)"],"Date":"Tue, 12 Sep 2017 12:36:28 +0200","From":"Pavel Machek ","To":"Sakari Ailus ,\n\tjacek.anaszewski@gmail.com, linux-leds@vger.kernel.org","Cc":"linux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"as3645a flash userland interface ","Message-ID":"<20170912103628.GB27117@amd>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"qlTNgmc+xy1dBmNv\"","Content-Disposition":"inline","In-Reply-To":"<20170912084236.1154-25-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":1766870,"web_url":"http://patchwork.ozlabs.org/comment/1766870/","msgid":"<20170912104720.ifyouc5pa5et6gzk@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-12T10:47:20","subject":"Re: as3645a flash userland interface","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Hi Pavel,\n\nOn Tue, Sep 12, 2017 at 12:36:28PM +0200, Pavel Machek wrote:\n> Hi!\n> \n> There were some changes to as3645a flash controller. Before we have\n> stable interface we have to keep forever I want to ask:\n> \n> What directory are the flash controls in?\n> \n> /sys/class/leds/led-controller:flash ?\n> \n> Could we arrange for something less generic, like\n> \n> /sys/class/leds/main-camera:flash ?\n> \n> Thanks,\n\nThe LEDs are called as3645a:flash and as3645a:indicator currently, based on\nthe name of the LED controller's device node. There are no patches related\nto this set though; these have already been merged.\n\nThe label should be a \"human readable string describing the device\" (from\nePAPR, please excuse me for not having a newer spec), and the led common\nbindings define it as:\n\n- label : The label for this LED. If omitted, the label is taken from the node\n name (excluding the unit address). It has to uniquely identify\n a device, i.e. no other LED class device can be assigned the same\n label.\n\nI don't think that you should be looking to use this to associate it with\nthe camera as such. The association information with the sensor is\navailable to the kernel but there's no interface that could meaningfully\nexpose it to the user right now.","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 3xs1hZ2lcRz9s7g\n\tfor ;\n\tTue, 12 Sep 2017 20:47:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751384AbdILKrY (ORCPT\n\t);\n\tTue, 12 Sep 2017 06:47:24 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:34920 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751381AbdILKrY (ORCPT\n\t); Tue, 12 Sep 2017 06:47:24 -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 5297E600F6;\n\tTue, 12 Sep 2017 13:47:21 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1driiu-0003va-P0; Tue, 12 Sep 2017 13:47:20 +0300"],"Date":"Tue, 12 Sep 2017 13:47:20 +0300","From":"Sakari Ailus ","To":"Pavel Machek ","Cc":"Sakari Ailus ,\n\tjacek.anaszewski@gmail.com, linux-leds@vger.kernel.org,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170912104720.ifyouc5pa5et6gzk@valkosipuli.retiisi.org.uk>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170912103628.GB27117@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":1766921,"web_url":"http://patchwork.ozlabs.org/comment/1766921/","msgid":"<20170912114051.GA1655@amd>","list_archive_url":null,"date":"2017-09-12T11:40:51","subject":"Re: as3645a flash userland interface","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> On Tue, Sep 12, 2017 at 12:36:28PM +0200, Pavel Machek wrote:\n> > Hi!\n> > \n> > There were some changes to as3645a flash controller. Before we have\n> > stable interface we have to keep forever I want to ask:\n> > \n> > What directory are the flash controls in?\n> > \n> > /sys/class/leds/led-controller:flash ?\n> > \n> > Could we arrange for something less generic, like\n> > \n> > /sys/class/leds/main-camera:flash ?\n> > \n> > Thanks,\n> \n> The LEDs are called as3645a:flash and as3645a:indicator currently, based on\n> the name of the LED controller's device node. There are no patches related\n> to this set though; these have already been merged.\n> \n> The label should be a \"human readable string describing the device\" (from\n> ePAPR, please excuse me for not having a newer spec), and the led common\n> bindings define it as:\n> \n> - label : The label for this LED. If omitted, the label is taken from the node\n> name (excluding the unit address). It has to uniquely identify\n> a device, i.e. no other LED class device can be assigned the same\n> label.\n\nOk, can we set the label to \"main_camera\" for N9 and n950 cases?\n\n\"as3645a:flash\" is really wrong name for a LED. Information that\nas3645 is already present elsewhere in /sys. Information where the LED\nis and what it does is not.\n\nI'd like to have torch application that just writes\n/sys/class/leds/main_camera:white:flash/brightness . It should not\nneed to know hardware details of differnet phones.\n\n> I don't think that you should be looking to use this to associate it with\n> the camera as such. The association information with the sensor is\n> available to the kernel but there's no interface that could meaningfully\n> expose it to the user right now.\n\nYeah, I'm not looking for sensor association. I'm looking for\nreasonable userland interface.\n\nThanks,\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 3xs2tH59Dmz9s7B\n\tfor ;\n\tTue, 12 Sep 2017 21:40:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751337AbdILLky (ORCPT\n\t);\n\tTue, 12 Sep 2017 07:40:54 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:46809 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751289AbdILLkx (ORCPT\n\t); Tue, 12 Sep 2017 07:40:53 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid D8F2C82512; Tue, 12 Sep 2017 13:40:51 +0200 (CEST)"],"Date":"Tue, 12 Sep 2017 13:40:51 +0200","From":"Pavel Machek ","To":"Sakari Ailus ","Cc":"Sakari Ailus ,\n\tjacek.anaszewski@gmail.com, linux-leds@vger.kernel.org,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170912114051.GA1655@amd>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<20170912104720.ifyouc5pa5et6gzk@valkosipuli.retiisi.org.uk>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"0F1p//8PRICkK4MW\"","Content-Disposition":"inline","In-Reply-To":"<20170912104720.ifyouc5pa5et6gzk@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":1766932,"web_url":"http://patchwork.ozlabs.org/comment/1766932/","msgid":"<20170912120447.yqdwbdfgd7ac4xpn@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-12T12:04:47","subject":"Re: as3645a flash userland interface","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Ahoy!\n\nOn Tue, Sep 12, 2017 at 01:40:51PM +0200, Pavel Machek wrote:\n> Hi!\n> \n> > On Tue, Sep 12, 2017 at 12:36:28PM +0200, Pavel Machek wrote:\n> > > Hi!\n> > > \n> > > There were some changes to as3645a flash controller. Before we have\n> > > stable interface we have to keep forever I want to ask:\n> > > \n> > > What directory are the flash controls in?\n> > > \n> > > /sys/class/leds/led-controller:flash ?\n> > > \n> > > Could we arrange for something less generic, like\n> > > \n> > > /sys/class/leds/main-camera:flash ?\n> > > \n> > > Thanks,\n> > \n> > The LEDs are called as3645a:flash and as3645a:indicator currently, based on\n> > the name of the LED controller's device node. There are no patches related\n> > to this set though; these have already been merged.\n> > \n> > The label should be a \"human readable string describing the device\" (from\n> > ePAPR, please excuse me for not having a newer spec), and the led common\n> > bindings define it as:\n> > \n> > - label : The label for this LED. If omitted, the label is taken from the node\n> > name (excluding the unit address). It has to uniquely identify\n> > a device, i.e. no other LED class device can be assigned the same\n> > label.\n> \n> Ok, can we set the label to \"main_camera\" for N9 and n950 cases?\n> \n> \"as3645a:flash\" is really wrong name for a LED. Information that\n> as3645 is already present elsewhere in /sys. Information where the LED\n> is and what it does is not.\n> \n> I'd like to have torch application that just writes\n> /sys/class/leds/main_camera:white:flash/brightness . It should not\n> need to know hardware details of differnet phones.\n\nHmm. There don't seem to be a uniform way to form labels.\n\nWhat I'd do is to look up a LED that implements LED flash class and use\nthat; it's a flash LED and is likely to be the most powerful in the system.\nThere could be several as well, some more recent flash controllers have\nmore than one.\n\nI wonder what Jacek thinks.\n\n> \n> > I don't think that you should be looking to use this to associate it with\n> > the camera as such. The association information with the sensor is\n> > available to the kernel but there's no interface that could meaningfully\n> > expose it to the user right now.\n> \n> Yeah, I'm not looking for sensor association. I'm looking for\n> reasonable userland interface.\n\nAck. Hopefully we can provide the association some day, 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 3xs3QL5tXtz9sRm\n\tfor ;\n\tTue, 12 Sep 2017 22:04:53 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751379AbdILMEv (ORCPT\n\t);\n\tTue, 12 Sep 2017 08:04:51 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:35532 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751375AbdILMEu (ORCPT\n\t); Tue, 12 Sep 2017 08:04:50 -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 8A1E6600F3;\n\tTue, 12 Sep 2017 15:04:48 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1drjvs-0003w6-1H; Tue, 12 Sep 2017 15:04:48 +0300"],"Date":"Tue, 12 Sep 2017 15:04:47 +0300","From":"Sakari Ailus ","To":"Pavel Machek ","Cc":"Sakari Ailus ,\n\tjacek.anaszewski@gmail.com, linux-leds@vger.kernel.org,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170912120447.yqdwbdfgd7ac4xpn@valkosipuli.retiisi.org.uk>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<20170912104720.ifyouc5pa5et6gzk@valkosipuli.retiisi.org.uk>\n\t<20170912114051.GA1655@amd>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170912114051.GA1655@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":1767292,"web_url":"http://patchwork.ozlabs.org/comment/1767292/","msgid":"<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>","list_archive_url":null,"date":"2017-09-12T18:53:33","subject":"Re: as3645a flash userland interface","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/12/2017 12:36 PM, Pavel Machek wrote:\n> Hi!\n> \n> There were some changes to as3645a flash controller. Before we have\n> stable interface we have to keep forever I want to ask:\n\nNote that we have already two LED flash class drivers - leds-max77693\nand leds-aat1290. They have been present in mainline for over two years\nnow.\n\n> What directory are the flash controls in?\n> \n> /sys/class/leds/led-controller:flash ?\n> \n> Could we arrange for something less generic, like\n> \n> /sys/class/leds/main-camera:flash ?\n\nI'd rather avoid overcomplicating this. LED class device name pattern\nis well defined to devicename:colour:function\n(see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n\nIn this case \"flash\" in place of the \"function\" segment makes the\nthings clear enough I suppose.","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=\"uayaNwu3\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xsDVb0sn3z9s8J\n\tfor ;\n\tWed, 13 Sep 2017 04:54:31 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751308AbdILSy3 (ORCPT\n\t);\n\tTue, 12 Sep 2017 14:54:29 -0400","from mail-wm0-f53.google.com ([74.125.82.53]:43651 \"EHLO\n\tmail-wm0-f53.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751048AbdILSy2 (ORCPT\n\t); Tue, 12 Sep 2017 14:54:28 -0400","by mail-wm0-f53.google.com with SMTP id a137so1998045wma.0;\n\tTue, 12 Sep 2017 11:54:27 -0700 (PDT)","from [192.168.1.18] (ckm50.neoplus.adsl.tpnet.pl. [83.31.88.50])\n\tby smtp.gmail.com with ESMTPSA id\n\tu8sm5484744edj.73.2017.09.12.11.54.24\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 12 Sep 2017 11:54:25 -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=IqBZ5Ix7GKaF3zVGJAYCabFqSyoDzObckpmX9LsuX1A=;\n\tb=uayaNwu31i28hanndsoRIqI9e82xaueyNhR2rKJR0xj5N6EyjWtXlcbJNMw3+tWUPR\n\taIVJ0Df6uHNIW2YwrYeM9DNG1PSiwSm+ylb1Wr2XdACiWp7cri+/XWdo+5RzSOfZb2FU\n\t/GDjO2hZ3WhWl8SdrlTz0zumXjBvQirz+IC+AUQ36tqT6YGX7GImHhJTjNHZDgB7My4r\n\tBx5PD5hDc3q2XPogk0DMc9EIN4fiDsrXpq8r3CD7GPIiF+ufWtJcYwTKCG9TcA8JyMka\n\tytkDP7L8OwyrgjQdoHJJ3KJhzEOButplV68hplznsK4EnQkfzZUQSNsBKe8YVfFH5iFe\n\t4wAw==","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=IqBZ5Ix7GKaF3zVGJAYCabFqSyoDzObckpmX9LsuX1A=;\n\tb=mTuenkXnqdeEWh//3K7Z1cZTnaybwD+jVfgMTq6gqmBjdcANuaZYdxpD4dA4IVy+Tk\n\tkf6ss3VLnHkK6vCR5w9ngqPyznu+CKS/b9vNUP/CbP88UBbUkTNbF6+R32aEgDUdrNXq\n\tQWpK+3UDfT08wlWKufDX1jTjASTYiwaD2tJIiFH3StNe8UTI9jnOgGc6Q2rX6i5yiGUK\n\tFq6VWjDqIaChzPb067sAUb8wyBxqhJvn0nFN6I/16aYKEHve+ZbdPLeA5T4JZQGmnVzG\n\tAyXrES9audcO5CVqGIRkivPiWWm/AUFNdVgxDQID4fLjot+IBB7f8+l6wbBlaBYTrSAR\n\thItw==","X-Gm-Message-State":"AHPjjUjfFiChh/vW95CWPa4bmVjW2JhgT9iBKGwaitpiY13clraPG+Dv\n\tDJYXwEpGA+lSJg==","X-Google-Smtp-Source":"ADKCNb7s3jhxscwUORAMH7KUEocc2FPUzQQB2VDWZP3aUS07T6Rrmei30oh8mwmWXyniR+beks5NBQ==","X-Received":"by 10.80.165.142 with SMTP id a14mr13790487edc.190.1505242466802;\n\tTue, 12 Sep 2017 11:54:26 -0700 (PDT)","Subject":"Re: as3645a flash userland interface","To":"Pavel Machek , Sakari Ailus ,\n\tlinux-leds@vger.kernel.org","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>","Cc":"linux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1010","Message-ID":"<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>","Date":"Tue, 12 Sep 2017 20:53: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":"<20170912103628.GB27117@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":1767400,"web_url":"http://patchwork.ozlabs.org/comment/1767400/","msgid":"<20170912215529.GA17218@amd>","list_archive_url":null,"date":"2017-09-12T21:55:29","subject":"Re: as3645a flash userland interface","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"On Tue 2017-09-12 20:53:33, Jacek Anaszewski wrote:\n> Hi Pavel,\n> \n> On 09/12/2017 12:36 PM, Pavel Machek wrote:\n> > Hi!\n> > \n> > There were some changes to as3645a flash controller. Before we have\n> > stable interface we have to keep forever I want to ask:\n> \n> Note that we have already two LED flash class drivers - leds-max77693\n> and leds-aat1290. They have been present in mainline for over two years\n> now.\n\nWell.. that's ok. No change there is neccessary.\n\n> > What directory are the flash controls in?\n> > \n> > /sys/class/leds/led-controller:flash ?\n> > \n> > Could we arrange for something less generic, like\n> > \n> > /sys/class/leds/main-camera:flash ?\n> \n> I'd rather avoid overcomplicating this. LED class device name pattern\n> is well defined to devicename:colour:function\n> (see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n> \n> In this case \"flash\" in place of the \"function\" segment makes the\n> things clear enough I suppose.\n\nIt does not.\n\nPhones usually have two cameras, front and back, and these days both\ncameras have their flash.\n\nAnd poor userspace flashlight application can not know if as3645\ndrivers front LED or back LED. Thus, I'd set devicename to\nfront-camera or main-camera -- because that's what it is associated\nwith. Userspace does not care what hardware drives the LED, but needs\nto know if it is front or back camera.\n\nIf LEDs control keyboard backlight, I'd expect the LED name to be\n\"keyboard::backlight\", not \"i2c-0020-adp1643::backlight\".\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 3xsJWT3yQBz9t3J\n\tfor ;\n\tWed, 13 Sep 2017 07:55:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751105AbdILVzb (ORCPT\n\t);\n\tTue, 12 Sep 2017 17:55:31 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:41301 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751018AbdILVzb (ORCPT\n\t); Tue, 12 Sep 2017 17:55:31 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid AF2C78247D; Tue, 12 Sep 2017 23:55:29 +0200 (CEST)"],"Date":"Tue, 12 Sep 2017 23:55:29 +0200","From":"Pavel Machek ","To":"Jacek Anaszewski ","Cc":"Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170912215529.GA17218@amd>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"7AUc2qLy4jB3hD7Z\"","Content-Disposition":"inline","In-Reply-To":"<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.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":1768065,"web_url":"http://patchwork.ozlabs.org/comment/1768065/","msgid":"<21824758-28a1-7007-6db5-86a900025d14@gmail.com>","list_archive_url":null,"date":"2017-09-13T17:53:08","subject":"Re: as3645a flash userland interface","submitter":{"id":66885,"url":"http://patchwork.ozlabs.org/api/people/66885/","name":"Jacek Anaszewski","email":"jacek.anaszewski@gmail.com"},"content":"On 09/12/2017 11:55 PM, Pavel Machek wrote:\n> On Tue 2017-09-12 20:53:33, Jacek Anaszewski wrote:\n>> Hi Pavel,\n>>\n>> On 09/12/2017 12:36 PM, Pavel Machek wrote:\n>>> Hi!\n>>>\n>>> There were some changes to as3645a flash controller. Before we have\n>>> stable interface we have to keep forever I want to ask:\n>>\n>> Note that we have already two LED flash class drivers - leds-max77693\n>> and leds-aat1290. They have been present in mainline for over two years\n>> now.\n> \n> Well.. that's ok. No change there is neccessary.\n> \n>>> What directory are the flash controls in?\n>>>\n>>> /sys/class/leds/led-controller:flash ?\n>>>\n>>> Could we arrange for something less generic, like\n>>>\n>>> /sys/class/leds/main-camera:flash ?\n>>\n>> I'd rather avoid overcomplicating this. LED class device name pattern\n>> is well defined to devicename:colour:function\n>> (see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n>>\n>> In this case \"flash\" in place of the \"function\" segment makes the\n>> things clear enough I suppose.\n> \n> It does not.\n> \n> Phones usually have two cameras, front and back, and these days both\n> cameras have their flash.\n> \n> And poor userspace flashlight application can not know if as3645\n> drivers front LED or back LED. Thus, I'd set devicename to\n> front-camera or main-camera -- because that's what it is associated\n> with. Userspace does not care what hardware drives the LED, but needs\n> to know if it is front or back camera.\n\nThe name of a LED flash class device isn't fixed and is derived\nfrom DT label property. Name in the example of some DT bindings\nwill not force people to apply similar pattern for the other\ndrivers and even for the related one. No worry about having\nto keep anything forever basing on that.","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=\"H9RbSv5p\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xsq6R6cfKz9s7g\n\tfor ;\n\tThu, 14 Sep 2017 03:54:07 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751279AbdIMRyG (ORCPT\n\t);\n\tWed, 13 Sep 2017 13:54:06 -0400","from mail-wm0-f66.google.com ([74.125.82.66]:32896 \"EHLO\n\tmail-wm0-f66.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751106AbdIMRyD (ORCPT\n\t); Wed, 13 Sep 2017 13:54:03 -0400","by mail-wm0-f66.google.com with SMTP id 187so1216822wmn.0;\n\tWed, 13 Sep 2017 10:54:03 -0700 (PDT)","from [192.168.1.18] (ckm50.neoplus.adsl.tpnet.pl. [83.31.88.50])\n\tby smtp.gmail.com with ESMTPSA id\n\tz66sm750372wmh.36.2017.09.13.10.54.00\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 13 Sep 2017 10:54:01 -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=M00Vu9Wo98wIgJ3aGbqvslkkhKv0Yib0P41TdXJ47O8=;\n\tb=H9RbSv5pX2dRjwaJUMlCPr6A82UHGQ8OllbeBP+OsZlUcMhXYbYWqxEPEp2IQuvZdj\n\tmHVrp70vLJAFki1kb9hztcvNGStEgEClAE1iruxCbwOXZ0wohckdCvGWhP2wXclHd2SN\n\tUGQdk05Oos9Bo1yww6E7FWe3C52ICo3PYOU4Va7L4KEZP/2aZ8l4KxmHVW4FWfp+CQ+c\n\tr+w/3MW8O/69FWFQu8fw7UMCznNZFqcdBJEyCzzPnj7hjflDBQLTLWOmuUaPvzYbqtYi\n\tTtZgk/htn4BO7f0cygCXUuYOKKSs6YYnAE+El8ZDjc85Xa/7YEI7vYQkgnONTk58MlB+\n\tCOfA==","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=M00Vu9Wo98wIgJ3aGbqvslkkhKv0Yib0P41TdXJ47O8=;\n\tb=SUzeygpQQUDA2KtEMfA4OkrO2ZoJzgYjmsNNeiCSk7ggFi9arq6RrysMGd3U1/Sxcb\n\tMa2OnvQSv0gd1BW3OLr+1nh3M/eD6BuKatNOzsp7pUzjhpZ31PX2C5bh6AZ47EOZdaQf\n\tKMMugNtu1JmFuO7ec8vB6u1+AVdM4vOBMSLaHEBg9XrbNafo+VHnoh8LY0uJLQ/qc3CD\n\tgYkP5B3y9I7vuPs02TfpaPQRdvAKnXQWd1xZgoDmOAQ/p2d5KX+RBnwW/x/cTLGAfbWq\n\t+7ffS1MiOM1WeG0MVEP1Qw0hZsWpD2QNWNNXls++Qh8BYPgGiuMhMUw+DSsE7P9hUkJm\n\t/alA==","X-Gm-Message-State":"AHPjjUildcmqwLNHkCEjp+jJcCrMneBkAZWF1EkHrsr3qw1p1Slr9R85\n\t6V+/61csb7qUiW3dR6s=","X-Google-Smtp-Source":"AOwi7QDZMVkWpZcFSX0IjJ8h7riEaq9jZXu9QpF2eDzyuCnf4emBVvsnkzxLfYXO2so4T06X19tjKw==","X-Received":"by 10.28.111.73 with SMTP id k70mr2909569wmc.84.1505325242139;\n\tWed, 13 Sep 2017 10:54:02 -0700 (PDT)","Subject":"Re: as3645a flash userland interface","To":"Pavel Machek ","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>","Cc":"Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","From":"Jacek Anaszewski ","X-Enigmail-Draft-Status":"N1010","Message-ID":"<21824758-28a1-7007-6db5-86a900025d14@gmail.com>","Date":"Wed, 13 Sep 2017 19:53:08 +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":"<20170912215529.GA17218@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":1768449,"web_url":"http://patchwork.ozlabs.org/comment/1768449/","msgid":"<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>","list_archive_url":null,"date":"2017-09-14T09:24:10","subject":"Re: as3645a flash userland interface","submitter":{"id":11222,"url":"http://patchwork.ozlabs.org/api/people/11222/","name":"Sylwester Nawrocki","email":"s.nawrocki@samsung.com"},"content":"Hi,\n\nOn 09/13/2017 07:53 PM, Jacek Anaszewski wrote:\n> On 09/12/2017 11:55 PM, Pavel Machek wrote:\n>> On Tue 2017-09-12 20:53:33, Jacek Anaszewski wrote:\n>>> On 09/12/2017 12:36 PM, Pavel Machek wrote:\n\n>>>> What directory are the flash controls in?\n>>>>\n>>>> /sys/class/leds/led-controller:flash ?\n>>>>\n>>>> Could we arrange for something less generic, like\n>>>>\n>>>> /sys/class/leds/main-camera:flash ?\n>>>\n>>> I'd rather avoid overcomplicating this. LED class device name pattern\n>>> is well defined to devicename:colour:function\n>>> (see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n>>>\n>>> In this case \"flash\" in place of the \"function\" segment makes the\n>>> things clear enough I suppose.\n>>\n>> It does not.\n>>\n>> Phones usually have two cameras, front and back, and these days both\n>> cameras have their flash.\n>>\n>> And poor userspace flashlight application can not know if as3645\n>> drivers front LED or back LED. Thus, I'd set devicename to\n>> front-camera or main-camera -- because that's what it is associated\n>> with. Userspace does not care what hardware drives the LED, but needs\n>> to know if it is front or back camera.\n> \n> The name of a LED flash class device isn't fixed and is derived\n> from DT label property. Name in the example of some DT bindings\n> will not force people to apply similar pattern for the other\n> drivers and even for the related one. No worry about having\n> to keep anything forever basing on that.\n\nIsn't the V4L2 subdev/Media Controller API supposed to provide means\nfor associating flash LEDs with camera sensors? You seem to be insisting\non using the sysfs leds interface for that, which is not a primary\ninterface for camera flash AFAICT.","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 3xtClm6d4xz9sPs\n\tfor ;\n\tThu, 14 Sep 2017 19:24:20 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751392AbdINJYT (ORCPT\n\t);\n\tThu, 14 Sep 2017 05:24:19 -0400","from mailout4.samsung.com ([203.254.224.34]:46205 \"EHLO\n\tmailout4.samsung.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751193AbdINJYS (ORCPT\n\t); Thu, 14 Sep 2017 05:24:18 -0400","from epcas2p4.samsung.com (unknown [182.195.41.56])\n\tby mailout4.samsung.com (KnoxPortal) with ESMTP id\n\t20170914092415epoutp04d3da51b7c8691fe786508fdecaefa51b~kMBg1DQZ81574815748epoutp04I;\n\tThu, 14 Sep 2017 09:24:15 +0000 (GMT)","from epsmges2p2.samsung.com (unknown [182.195.42.70]) by\n\tepcas2p4.samsung.com (KnoxPortal) with ESMTP id\n\t20170914092415epcas2p4193a58952d436b86af2657e844b7ea4d~kMBgjdy940731307313epcas2p4q;\n\tThu, 14 Sep 2017 09:24:15 +0000 (GMT)","from epcas2p2.samsung.com ( [182.195.41.54]) by\n\tepsmges2p2.samsung.com (Symantec Messaging Gateway) with SMTP id\n\t11.EF.15349.FBA4AB95; Thu, 14 Sep 2017 18:24:15 +0900 (KST)","from epsmgms2p2new.samsung.com (unknown [182.195.42.143]) by\n\tepcas2p2.samsung.com (KnoxPortal) with ESMTP id\n\t20170914092415epcas2p26c049a698851778673034c16afb290b9~kMBgO_1Yu2284022840epcas2p2a;\n\tThu, 14 Sep 2017 09:24:15 +0000 (GMT)","from epmmp2 ( [203.254.227.17]) by epsmgms2p2new.samsung.com\n\t(Symantec Messaging Gateway) with SMTP id 1A.7D.10338.FBA4AB95;\n\tThu, 14 Sep 2017 18:24:15 +0900 (KST)","from [106.116.147.40] by mmp2.samsung.com (Oracle Communications\n\tMessaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id\n\t<0OW9002WPJGA7V10@mmp2.samsung.com>;\n\tThu, 14 Sep 2017 18:24:15 +0900 (KST)"],"X-AuditID":"b6c32a46-f790d6d000003bf5-6a-59ba4abffddc","Subject":"Re: as3645a flash userland interface","To":"Pavel Machek ","Cc":"Jacek Anaszewski ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","From":"Sylwester Nawrocki ","Message-id":"<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>","Date":"Thu, 14 Sep 2017 11:24:10 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-version":"1.0","In-reply-to":"<21824758-28a1-7007-6db5-86a900025d14@gmail.com>","Content-type":"text/plain; charset=\"windows-1252\"; format=\"flowed\"","Content-language":"en-GB","Content-transfer-encoding":"7bit","X-Brightmail-Tracker":["H4sIAAAAAAAAA+NgFjrCKsWRmVeSWpSXmKPExsWy7bCmme5+r12RBhOOqFvMP3KO1eLU5GdM\n\tFre3bmCx6Jy4hN1i65t1jBY9G7ayWhyf1sdqcffUUTaL/3t2sFt82vKNyeL07hIHbo+ds+6y\n\te8zumMnqsWlVJ5vHvJOBHs8vf2fzWLH6O7vH501yHqe+fmYP4IjisklJzcksSy3St0vgypg9\n\t6SFrwUfeihstH1kaGOdwdzFyckgImEgsvruSHcIWk7hwbz1bFyMXh5DADkaJhkXLWSGc74wS\n\tf/4fYILpaF5/GyqxgVGitXMZE4Rzn1Hi3LlDYLOEBXQl9v67C2aLCMhLbO1bwQxSxCywiUni\n\t3awWsFFsAoYSvUf7GEFsXgE7iff/Z7CB2CwCqhJXtjWwgNiiAhES275DxHkFBCV+TL4HFucU\n\tsJU4uWgZWJxZwFHiwaKdrBC2uMSx+zcZIWx5ic1r3oItlhBoZpf4em8CC8QPLhLLlzxnhLCF\n\tJV4d3wINAWmJZ6s2MkI09DNKnFjTDOXMYJS40z4BGgLWEoePX4RaxyfRcfgvUDcHUJxXoqNN\n\tCKLEQ2LP7bNQyxwlds5qggbrByaJbVuesE5glJ+F5KNZSL6YheSLWUi+WMDIsopRLLWgODc9\n\ttdiowEivODG3uDQvXS85P3cTIzhtabntYFxyzucQowAHoxIP7wPLnZFCrIllxZW5hxglOJiV\n\tRHilHXdFCvGmJFZWpRblxxeV5qQWH2KU5mBREuet23YtQkggPbEkNTs1tSC1CCbLxMEp1cDo\n\tmDxhx6YloVOubP4Ru3zDCam1Ja2Vs6QkK6X+S70zvnb12IN37lmPGJfk96z4klc2Z/KH6Req\n\tr85rifLVM08Oc+bKOBC1oEInZWLU2rSmNxXVs+KeK79KWaCstv7YyTO/2nJl/B+utu/03bBm\n\tppXx/Pe/nx5Wq7KSbopctdQzdOHsLOFP3BwrlFiKMxINtZiLihMBy2U0nFcDAAA=","H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42I5/e+xoO5+r12RBt07hSzmHznHanFq8jMm\n\ti9tbN7BYdE5cwm6x9c06RoueDVtZLY5P62O1uHvqKJvF/z072C0+bfnGZHF6d4kDt8fOWXfZ\n\tPWZ3zGT12LSqk81j3slAj+eXv7N5rFj9nd3j8yY5j1NfP7MHcERx2aSk5mSWpRbp2yVwZcye\n\t9JC14CNvxY2WjywNjHO4uxg5OSQETCSa199m7WLk4hASWMco8b/3ExOE85BRYuGpDlaQKmEB\n\tXYm9/+6yg9giAvISW/tWMIMUMQtsYpLYu+oMG0THDCaJWZ2vmECq2AQMJXqP9jGC2LwCdhLv\n\t/89gA7FZBFQlrmxrYAGxRQUiJPreXmaHqBGU+DH5HlicU8BW4uSiZWD1zED2gvfrWCBscYlj\n\t928yQtjyEpvXvGWewCgwC0n7LCQts5C0zELSsoCRZRWjZGpBcW56brFRgVFearlecWJucWle\n\tul5yfu4mRmA0bTus1b+D8fGS+EOMAhyMSjy8Dyx3RgqxJpYVV+YeYpTgYFYS4ZV23BUpxJuS\n\tWFmVWpQfX1Sak1p8iFGag0VJnDezb0akkEB6YklqdmpqQWoRTJaJg1OqgVGHfeGSVXOblihd\n\tV9deGioa5lwYyJkyX15S1+zhntoks/Rfazfpc/5lrJEObJjAtPkO86fnU/o4y9SNT9bwLVdh\n\tvtbX8M7+MvPr3Gl+Gkc/xF+12Dpx2p3mtrNTtxXOjjjQMG/j/ZjJk5eH9T7ZdrSxKSRJ6Mdu\n\tHrODSxP/lCiHN+zepRjJ9leJpTgj0VCLuag4EQBZigHoogIAAA=="],"X-CMS-MailID":"20170914092415epcas2p26c049a698851778673034c16afb290b9","X-Msg-Generator":"CA","X-Sender-IP":"182.195.42.143","X-Local-Sender":"=?utf-8?q?Sylwester_Nawrocki=1BSRPOL-Kernel_=28TP=29=1B?=\n\t=?utf-8?b?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?=","X-Global-Sender":"=?utf-8?q?Sylwester_Nawrocki=1BSRPOL-Kernel_=28TP=29=1BS?=\n\t=?utf-8?q?amsung_Electronics=1BSenior_Software_Engineer?=","X-Sender-Code":"=?utf-8?q?C10=1BEHQ=1BC10CD02CD027392?=","CMS-TYPE":"102P","X-CMS-RootMailID":"20170914092415epcas2p26c049a698851778673034c16afb290b9","X-RootMTR":"20170914092415epcas2p26c049a698851778673034c16afb290b9","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>\n\t<21824758-28a1-7007-6db5-86a900025d14@gmail.com>\n\t","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1768489,"web_url":"http://patchwork.ozlabs.org/comment/1768489/","msgid":"<20170914100718.GA3843@amd>","list_archive_url":null,"date":"2017-09-14T10:07:18","subject":"Re: as3645a flash userland interface","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"Hi!\n\n> >>>>What directory are the flash controls in?\n> >>>>\n> >>>>/sys/class/leds/led-controller:flash ?\n> >>>>\n> >>>>Could we arrange for something less generic, like\n> >>>>\n> >>>>/sys/class/leds/main-camera:flash ?\n> >>>\n> >>>I'd rather avoid overcomplicating this. LED class device name pattern\n> >>>is well defined to devicename:colour:function\n> >>>(see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n> >>>\n> >>>In this case \"flash\" in place of the \"function\" segment makes the\n> >>>things clear enough I suppose.\n> >>\n> >>It does not.\n> >>\n> >>Phones usually have two cameras, front and back, and these days both\n> >>cameras have their flash.\n> >>\n> >>And poor userspace flashlight application can not know if as3645\n> >>drivers front LED or back LED. Thus, I'd set devicename to\n> >>front-camera or main-camera -- because that's what it is associated\n> >>with. Userspace does not care what hardware drives the LED, but needs\n> >>to know if it is front or back camera.\n> >\n> >The name of a LED flash class device isn't fixed and is derived\n> >from DT label property. Name in the example of some DT bindings\n> >will not force people to apply similar pattern for the other\n> >drivers and even for the related one. No worry about having\n> >to keep anything forever basing on that.\n> \n> Isn't the V4L2 subdev/Media Controller API supposed to provide means\n> for associating flash LEDs with camera sensors? You seem to be insisting\n> on using the sysfs leds interface for that, which is not a primary\n> interface for camera flash AFAICT.\n\na) subdev/media controller API currently does not provide such means.\n\nb) if we have /sys/class/leds interface to userland, it should be\nuseful.\n\nc) having flashlight application going through media controller API is\na bad joke.\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 3xtDjR4wcLz9sRg\n\tfor ;\n\tThu, 14 Sep 2017 20:07:23 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751476AbdINKHV (ORCPT\n\t);\n\tThu, 14 Sep 2017 06:07:21 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:35853 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751277AbdINKHV (ORCPT\n\t); Thu, 14 Sep 2017 06:07:21 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid 32CFC824D2; Thu, 14 Sep 2017 12:07:19 +0200 (CEST)"],"Date":"Thu, 14 Sep 2017 12:07:18 +0200","From":"Pavel Machek ","To":"Sylwester Nawrocki ","Cc":"Jacek Anaszewski ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170914100718.GA3843@amd>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>\n\t<21824758-28a1-7007-6db5-86a900025d14@gmail.com>\n\t\n\t<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"sm4nu43k4a2Rpi4c\"","Content-Disposition":"inline","In-Reply-To":"<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.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":1768499,"web_url":"http://patchwork.ozlabs.org/comment/1768499/","msgid":"","list_archive_url":null,"date":"2017-09-14T10:28:25","subject":"Re: as3645a flash userland interface","submitter":{"id":65485,"url":"http://patchwork.ozlabs.org/api/people/65485/","name":"Sakari Ailus","email":"sakari.ailus@linux.intel.com"},"content":"Hi Pavel and others,\n\nOn 09/14/17 13:07, Pavel Machek wrote:\n> Hi!\n> \n>>>>>> What directory are the flash controls in?\n>>>>>>\n>>>>>> /sys/class/leds/led-controller:flash ?\n>>>>>>\n>>>>>> Could we arrange for something less generic, like\n>>>>>>\n>>>>>> /sys/class/leds/main-camera:flash ?\n>>>>>\n>>>>> I'd rather avoid overcomplicating this. LED class device name pattern\n>>>>> is well defined to devicename:colour:function\n>>>>> (see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n>>>>>\n>>>>> In this case \"flash\" in place of the \"function\" segment makes the\n>>>>> things clear enough I suppose.\n>>>>\n>>>> It does not.\n>>>>\n>>>> Phones usually have two cameras, front and back, and these days both\n>>>> cameras have their flash.\n>>>>\n>>>> And poor userspace flashlight application can not know if as3645\n>>>> drivers front LED or back LED. Thus, I'd set devicename to\n>>>> front-camera or main-camera -- because that's what it is associated\n>>>> with. Userspace does not care what hardware drives the LED, but needs\n>>>> to know if it is front or back camera.\n>>>\n>>> The name of a LED flash class device isn't fixed and is derived\n>> >from DT label property. Name in the example of some DT bindings\n>>> will not force people to apply similar pattern for the other\n>>> drivers and even for the related one. No worry about having\n>>> to keep anything forever basing on that.\n>>\n>> Isn't the V4L2 subdev/Media Controller API supposed to provide means\n>> for associating flash LEDs with camera sensors? You seem to be \n\nIt should, and will, but doesn't do that yet. The information will soon\navailable to the kernel but even that's not yet in mainline.\n\ninsisting\n>> on using the sysfs leds interface for that, which is not a primary\n>> interface for camera flash AFAICT.\n> \n> a) subdev/media controller API currently does not provide such means.\n> \n> b) if we have /sys/class/leds interface to userland, it should be\n> useful.\n> \n> c) having flashlight application going through media controller API is\n> a bad joke.\n\nd) V4L2 sub-devices are always related to a master device (that usually\nhas the DMA engine). In the absence of that, there will be no sub-device\nnode either. In other words, if you don't have a camera, you won't have\na sub-device. And it's perfectly possible to have a flash LED without a\ncamera.\n\nFor what's worth, I think there was a Nokia (S30 ?) phone long, long\ntime ago with a torch LED but no camera. 1100 maybe? The old one, not\nthe new one.","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 3xtF9q5t6gz9sPs\n\tfor ;\n\tThu, 14 Sep 2017 20:28:31 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751414AbdINK2a (ORCPT\n\t);\n\tThu, 14 Sep 2017 06:28:30 -0400","from mga09.intel.com ([134.134.136.24]:60598 \"EHLO mga09.intel.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751385AbdINK2a (ORCPT );\n\tThu, 14 Sep 2017 06:28:30 -0400","from fmsmga004.fm.intel.com ([10.253.24.48])\n\tby orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;\n\t14 Sep 2017 03:28:29 -0700","from paasikivi.fi.intel.com ([10.237.72.42])\n\tby fmsmga004.fm.intel.com with ESMTP; 14 Sep 2017 03:28:25 -0700","from [127.0.0.1] (localhost [127.0.0.1])\n\tby paasikivi.fi.intel.com (Postfix) with ESMTP id 4C89320127;\n\tThu, 14 Sep 2017 13:28:25 +0300 (EEST)"],"X-ExtLoop1":"1","X-IronPort-AV":"E=Sophos;i=\"5.42,392,1500966000\"; \n\td=\"asc'?scan'208\";a=\"311590765\"","Subject":"Re: as3645a flash userland interface","To":"Pavel Machek , Sylwester Nawrocki ","Cc":"Jacek Anaszewski ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>\n\t<21824758-28a1-7007-6db5-86a900025d14@gmail.com>\n\t\n\t<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>\n\t<20170914100718.GA3843@amd>","From":"Sakari Ailus ","Message-ID":"","Date":"Thu, 14 Sep 2017 13:28:25 +0300","User-Agent":"Mozilla/5.0 (X11; Linux i686 on x86_64; rv:51.0) Gecko/20100101\n\tSeaMonkey/2.48","MIME-Version":"1.0","In-Reply-To":"<20170914100718.GA3843@amd>","Content-Type":"multipart/signed; micalg=pgp-sha256;\n\tprotocol=\"application/pgp-signature\";\n\tboundary=\"rFGVvDL23ikOeRt0JaKfX988RiQMeOQDP\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1768509,"web_url":"http://patchwork.ozlabs.org/comment/1768509/","msgid":"<1f34a891-edb1-251c-86a8-ba4a90c485d3@samsung.com>","list_archive_url":null,"date":"2017-09-14T11:01:19","subject":"Re: as3645a flash userland interface","submitter":{"id":11222,"url":"http://patchwork.ozlabs.org/api/people/11222/","name":"Sylwester Nawrocki","email":"s.nawrocki@samsung.com"},"content":"On 09/14/2017 12:07 PM, Pavel Machek wrote:\n>> Isn't the V4L2 subdev/Media Controller API supposed to provide means\n>> for associating flash LEDs with camera sensors? You seem to be insisting\n>> on using the sysfs leds interface for that, which is not a primary\n>> interface for camera flash AFAICT.\n >\n> a) subdev/media controller API currently does not provide such means.\n\nYes, but it should, that's what it was designed for AFAIK.\n\n> b) if we have /sys/class/leds interface to userland, it should be\n> useful.\n\nAt the same time we shouldn't overcomplicate it with the camera\nfunctionality.\n\n> c) having flashlight application going through media controller API is\n> a bad joke.\n\nIt doesn't have to, maybe I misunderstood what you exactly ask for.\nNevertheless what's missing is some user visible name/label for each\nflash LED, right? Currently enumerating flash LEDs can be done by looking\nat the function part of /sys/class/leds/::\n path.\n\nCould additional information be appended to the part, so\nuser can identify which LED is which? E.g. \"flash(rear)\", \"flash(front)\",\netc. This could be achieved by simply adding label property in DT.\nOr is the list of supported strings already standardized?","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 3xtFvw0GqCz9sRW\n\tfor ;\n\tThu, 14 Sep 2017 21:01:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751880AbdINLB3 (ORCPT\n\t);\n\tThu, 14 Sep 2017 07:01:29 -0400","from mailout2.samsung.com ([203.254.224.25]:39594 \"EHLO\n\tmailout2.samsung.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751784AbdINLB2 (ORCPT\n\t); Thu, 14 Sep 2017 07:01:28 -0400","from epcas2p4.samsung.com (unknown [182.195.41.56])\n\tby mailout2.samsung.com (KnoxPortal) with ESMTP id\n\t20170914110126epoutp0219ef18ceac246579245c6fbec35991a4~kNWWe96Rz1999619996epoutp02K;\n\tThu, 14 Sep 2017 11:01:26 +0000 (GMT)","from epsmges2p1.samsung.com (unknown [182.195.42.69]) by\n\tepcas2p1.samsung.com (KnoxPortal) with ESMTP id\n\t20170914110125epcas2p1b8c96f8878646d26f14b879b3ab29b63~kNWWTSESU2928829288epcas2p1U;\n\tThu, 14 Sep 2017 11:01:25 +0000 (GMT)","from epcas2p3.samsung.com ( [182.195.41.55]) by\n\tepsmges2p1.samsung.com (Symantec Messaging Gateway) with SMTP id\n\tF1.FA.10950.5816AB95; Thu, 14 Sep 2017 20:01:25 +0900 (KST)","from epsmgms2p2new.samsung.com (unknown [182.195.42.143]) by\n\tepcas2p4.samsung.com (KnoxPortal) with ESMTP id\n\t20170914110125epcas2p4554bf617f2e0404ec8d2212eb3bf019d~kNWVnnzzn1331513315epcas2p4K;\n\tThu, 14 Sep 2017 11:01:25 +0000 (GMT)","from epmmp2 ( [203.254.227.17]) by epsmgms2p2new.samsung.com\n\t(Symantec Messaging Gateway) with SMTP id 88.85.10338.4816AB95;\n\tThu, 14 Sep 2017 20:01:25 +0900 (KST)","from [106.116.147.40] by mmp2.samsung.com (Oracle Communications\n\tMessaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id\n\t<0OW9000L3NY8EQA0@mmp2.samsung.com>;\n\tThu, 14 Sep 2017 20:01:24 +0900 (KST)"],"X-AuditID":"b6c32a45-f79466d000002ac6-55-59ba61857bae","Subject":"Re: as3645a flash userland interface","To":"Pavel Machek ,\n\tJacek Anaszewski ","Cc":"Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","From":"Sylwester Nawrocki ","Message-id":"<1f34a891-edb1-251c-86a8-ba4a90c485d3@samsung.com>","Date":"Thu, 14 Sep 2017 13:01:19 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-version":"1.0","In-reply-to":"<20170914100718.GA3843@amd>","Content-type":"text/plain; charset=\"windows-1252\"; format=\"flowed\"","Content-language":"en-GB","Content-transfer-encoding":"7bit","X-Brightmail-Tracker":["H4sIAAAAAAAAA+NgFjrMKsWRmVeSWpSXmKPExsWy7bCmuW5r4q5Ig3mb9SzmHznHanFq8jMm\n\ti9tbN7BYdE5cwm6x9c06RoueDVtZLY5P62O1uHvqKJvF/z072C0+bfnGZHF6d4kDt8fOWXfZ\n\tPWZ3zGT12LSqk81j3slAj+eXv7N5rFj9nd3j8yY5j1NfP7MHcERx2aSk5mSWpRbp2yVwZWy/\n\t9YGtYBFXxc4/i1kaGNdxdDFyckgImEjc3jeVCcIWk7hwbz1bFyMXh5DADkaJC9P6WSCc74wS\n\te6d0M8J0vN58gR0isYFRYtuSz1BV9xklmhcvZgOpEhbQldj77y47iC0iECDRfPIFWBGzQCOT\n\txIa3S8FGsQkYSvQe7QOzeQXsJPrnvGYGsVkEVCU+TXgFFhcViJDY9n0GG0SNoMSPyfeABnFw\n\tcApoSPT8zgMJMws4SjxYtJMVwhaXOHb/JiOELS+xec1bZpC9EgL/2ST+92xjh3jBReJ2+zRm\n\tCFtY4tXxLVBxaYlnqzYyQjT0M0qcWNMM5cxglLjTPgEaTNYSh49fhFrHJ9Fx+C87yEUSArwS\n\tHW1CECUeEntun2WBsB0lds5qgobqYWaJRd962CYwys9C8tAsJF/MQvLFLCRfLGBkWcUollpQ\n\tnJueWmxUYKhXnJhbXJqXrpecn7uJEZy0tFx3MM4453OIUYCDUYmH94Hlzkgh1sSy4srcQ4wS\n\tHMxKIrw/gndFCvGmJFZWpRblxxeV5qQWH2KU5mBREuet33YtQkggPbEkNTs1tSC1CCbLxMEp\n\t1cCYyGhXdX3R3uX8HAJn7SI7J/Gt/5y58WL691kFyeaNanL70yt010ceaBZZ8PTM4oklft7R\n\tv9nKQ79n/K3f+uNtR6WcjYtqbltu1DKdrUffH/0icbcqYgG/Qksj76q3C1X69fLWTTntqbNk\n\txdyK/aviPa5LKa451nKowjC+JiqnqvVjx6bcPblKLMUZiYZazEXFiQDzzliGVgMAAA==","H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42I5/e+xoG5r4q5Ig+MTmS3mHznHanFq8jMm\n\ti9tbN7BYdE5cwm6x9c06RoueDVtZLY5P62O1uHvqKJvF/z072C0+bfnGZHF6d4kDt8fOWXfZ\n\tPWZ3zGT12LSqk81j3slAj+eXv7N5rFj9nd3j8yY5j1NfP7MHcERx2aSk5mSWpRbp2yVwZWy/\n\t9YGtYBFXxc4/i1kaGNdxdDFyckgImEi83nyBvYuRi0NIYB2jxPoPV1ghnIeMElP6H7GDVAkL\n\t6Ers/XcXzBYR8JOY+PclWBGzQCOTxINr91ggOvYyS5yc9ooRpIpNwFCi92gfmM0rYCfRP+c1\n\tM4jNIqAq8WkCRI2oQIRE39vL7BA1ghI/JoMM4uDgFNCQ6PmdBxJmFrCVWPB+HQuELS5x7P5N\n\tRghbXmLzmrfMExgFZiHpnoWkZRaSlllIWhYwsqxilEwtKM5Nzy02KjDKSy3XK07MLS7NS9dL\n\tzs/dxAiMpW2Htfp3MD5eEn+IUYCDUYmH94Hlzkgh1sSy4srcQ4wSHMxKIrw/gndFCvGmJFZW\n\tpRblxxeV5qQWH2KU5mBREufN7JsRKSSQnliSmp2aWpBaBJNl4uCUamBcwLOg+0rzi4f51n2n\n\tpotNLONafEsgInXNZrePxRlz9i8N5532bvJSt41rk5asiPTI5LQvmK1/lLnOS1h+V6/Jtwdv\n\tGiZs5NCta+a9e3zm+YwTimWqgtYHXxVfKJWI2fG7J0eCU2bxzcVX+77nzwpfmV4xkSuz4LDF\n\t7z+Gr58J8XorT9O5xymrxFKckWioxVxUnAgAZCD/7aECAAA="],"X-CMS-MailID":"20170914110125epcas2p4554bf617f2e0404ec8d2212eb3bf019d","X-Msg-Generator":"CA","X-Sender-IP":"182.195.42.143","X-Local-Sender":"=?utf-8?q?Sylwester_Nawrocki=1BSRPOL-Kernel_=28TP=29=1B?=\n\t=?utf-8?b?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?=","X-Global-Sender":"=?utf-8?q?Sylwester_Nawrocki=1BSRPOL-Kernel_=28TP=29=1BS?=\n\t=?utf-8?q?amsung_Electronics=1BSenior_Software_Engineer?=","X-Sender-Code":"=?utf-8?q?C10=1BEHQ=1BC10CD02CD027392?=","CMS-TYPE":"102P","X-CMS-RootMailID":"20170914092415epcas2p26c049a698851778673034c16afb290b9","X-RootMTR":"20170914092415epcas2p26c049a698851778673034c16afb290b9","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>\n\t<21824758-28a1-7007-6db5-86a900025d14@gmail.com>\n\t\n\t<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>\n\t<20170914100718.GA3843@amd>","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1768537,"web_url":"http://patchwork.ozlabs.org/comment/1768537/","msgid":"<20170914115323.GA1850@amd>","list_archive_url":null,"date":"2017-09-14T11:53:23","subject":"Re: as3645a flash userland interface","submitter":{"id":2109,"url":"http://patchwork.ozlabs.org/api/people/2109/","name":"Pavel Machek","email":"pavel@ucw.cz"},"content":"On Thu 2017-09-14 13:01:19, Sylwester Nawrocki wrote:\n> On 09/14/2017 12:07 PM, Pavel Machek wrote:\n> >>Isn't the V4L2 subdev/Media Controller API supposed to provide means\n> >>for associating flash LEDs with camera sensors? You seem to be insisting\n> >>on using the sysfs leds interface for that, which is not a primary\n> >>interface for camera flash AFAICT.\n> >\n> >a) subdev/media controller API currently does not provide such means.\n> \n> Yes, but it should, that's what it was designed for AFAIK.\n> \n> >b) if we have /sys/class/leds interface to userland, it should be\n> >useful.\n> \n> At the same time we shouldn't overcomplicate it with the camera\n> functionality.\n\nI'm advocating adding label = \"main_camera\" into the .dts. That's all.\n\n> >c) having flashlight application going through media controller API is\n> >a bad joke.\n> \n> It doesn't have to, maybe I misunderstood what you exactly ask for.\n> Nevertheless what's missing is some user visible name/label for each\n> flash LED, right? Currently enumerating flash LEDs can be done by looking\n> at the function part of /sys/class/leds/::\n> path.\n> \n> Could additional information be appended to the part, so\n> user can identify which LED is which? E.g. \"flash(rear)\", \"flash(front)\",\n> etc. This could be achieved by simply adding label property in DT.\n> Or is the list of supported strings already standardized?\n\nlabel = \"flash_main_camera\" would work for me, yes. And yes, I'd\nprefer to do this before 4.14 release, so that userland-visible\ninterface does not change.\n\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 3xtH3q6mQSz9sPs\n\tfor ;\n\tThu, 14 Sep 2017 21:53:27 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751523AbdINLx0 (ORCPT\n\t);\n\tThu, 14 Sep 2017 07:53:26 -0400","from atrey.karlin.mff.cuni.cz ([195.113.26.193]:40310 \"EHLO\n\tatrey.karlin.mff.cuni.cz\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751323AbdINLxZ (ORCPT\n\t); Thu, 14 Sep 2017 07:53:25 -0400","by atrey.karlin.mff.cuni.cz (Postfix, from userid 512)\n\tid 0C483824DE; Thu, 14 Sep 2017 13:53:23 +0200 (CEST)"],"Date":"Thu, 14 Sep 2017 13:53:23 +0200","From":"Pavel Machek ","To":"Sylwester Nawrocki ","Cc":"Jacek Anaszewski ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170914115323.GA1850@amd>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>\n\t<21824758-28a1-7007-6db5-86a900025d14@gmail.com>\n\t\n\t<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>\n\t<20170914100718.GA3843@amd>\n\t<1f34a891-edb1-251c-86a8-ba4a90c485d3@samsung.com>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"+HP7ph2BbKc20aGI\"","Content-Disposition":"inline","In-Reply-To":"<1f34a891-edb1-251c-86a8-ba4a90c485d3@samsung.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":1768582,"web_url":"http://patchwork.ozlabs.org/comment/1768582/","msgid":"<82a4a519-e402-8eae-0352-e3e287fc508f@samsung.com>","list_archive_url":null,"date":"2017-09-14T13:16:29","subject":"Re: as3645a flash userland interface","submitter":{"id":11222,"url":"http://patchwork.ozlabs.org/api/people/11222/","name":"Sylwester Nawrocki","email":"s.nawrocki@samsung.com"},"content":"On 09/14/2017 01:53 PM, Pavel Machek wrote:\n> On Thu 2017-09-14 13:01:19, Sylwester Nawrocki wrote:\n>> On 09/14/2017 12:07 PM, Pavel Machek wrote:\n>>>> Isn't the V4L2 subdev/Media Controller API supposed to provide means\n>>>> for associating flash LEDs with camera sensors? You seem to be insisting\n>>>> on using the sysfs leds interface for that, which is not a primary\n>>>> interface for camera flash AFAICT.\n>>>\n>>> a) subdev/media controller API currently does not provide such means.\n>>\n>> Yes, but it should, that's what it was designed for AFAIK.\n>>\n>>> b) if we have /sys/class/leds interface to userland, it should be\n>>> useful.\n>>\n>> At the same time we shouldn't overcomplicate it with the camera\n>> functionality.\n> \n> I'm advocating adding label = \"main_camera\" into the .dts. That's all.\n> \n>>> c) having flashlight application going through media controller API is\n>>> a bad joke.\n>>\n>> It doesn't have to, maybe I misunderstood what you exactly ask for.\n>> Nevertheless what's missing is some user visible name/label for each\n>> flash LED, right? Currently enumerating flash LEDs can be done by looking\n>> at the function part of /sys/class/leds/::\n>> path.\n>>\n>> Could additional information be appended to the part, so\n>> user can identify which LED is which? E.g. \"flash(rear)\", \"flash(front)\",\n>> etc. This could be achieved by simply adding label property in DT.\n>> Or is the list of supported strings already standardized?\n> \n> label = \"flash_main_camera\" would work for me, yes. And yes, I'd\n> prefer to do this before 4.14 release, so that userland-visible\n> interface does not change.\n\nLooking at existing label entries in DT (git grep label.*led\n-- arch/arm/boot/dts | sed 's\\^.*label\\label\\' | sort | uniq)\nI can't see why something like this couldn't be added.\nOr label = \"as3645a::flash_main_camera\" so we abide the LED device\nnaming rules described in Documentation/leds/leds-class.txt.","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 3xtJvr2KS3z9sPs\n\tfor ;\n\tThu, 14 Sep 2017 23:16:40 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751165AbdINNQi (ORCPT\n\t);\n\tThu, 14 Sep 2017 09:16:38 -0400","from mailout2.samsung.com ([203.254.224.25]:57411 \"EHLO\n\tmailout2.samsung.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751131AbdINNQh (ORCPT\n\t); Thu, 14 Sep 2017 09:16:37 -0400","from epcas1p1.samsung.com (unknown [182.195.41.45])\n\tby mailout2.samsung.com (KnoxPortal) with ESMTP id\n\t20170914131635epoutp0209f25613ca4adf435e4f9c139575f8ed~kPMW-wHSP1079410794epoutp02K;\n\tThu, 14 Sep 2017 13:16:35 +0000 (GMT)","from epsmges1p3.samsung.com (unknown [182.195.42.55]) by\n\tepcas1p2.samsung.com (KnoxPortal) with ESMTP id\n\t20170914131635epcas1p2b224ca8a4aebe3354d10b66ccb5c6438~kPMWqqhjJ2171821718epcas1p2e;\n\tThu, 14 Sep 2017 13:16:35 +0000 (GMT)","from epcas1p4.samsung.com ( [182.195.41.48]) by\n\tepsmges1p3.samsung.com (Symantec Messaging Gateway) with SMTP id\n\tEA.3C.20246.3318AB95; Thu, 14 Sep 2017 22:16:35 +0900 (KST)","from epsmgms2p1new.samsung.com (unknown [182.195.42.142]) by\n\tepcas1p3.samsung.com (KnoxPortal) with ESMTP id\n\t20170914131634epcas1p363f283150d0d4dc43bc6072d1e691f9b~kPMWfCM5u3034630346epcas1p3W;\n\tThu, 14 Sep 2017 13:16:34 +0000 (GMT)","from epmmp2 ( [203.254.227.17]) by epsmgms2p1new.samsung.com\n\t(Symantec Messaging Gateway) with SMTP id D8.FE.11757.2318AB95;\n\tThu, 14 Sep 2017 22:16:34 +0900 (KST)","from [106.116.147.40] by mmp2.samsung.com (Oracle Communications\n\tMessaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id\n\t<0OW90001YU7IEQF0@mmp2.samsung.com>;\n\tThu, 14 Sep 2017 22:16:34 +0900 (KST)"],"X-AuditID":"b6c32a37-f79886d000004f16-10-59ba81331cf8","Subject":"Re: as3645a flash userland interface","To":"Pavel Machek ","Cc":"Jacek Anaszewski ,\n\tSakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","From":"Sylwester Nawrocki ","Message-id":"<82a4a519-e402-8eae-0352-e3e287fc508f@samsung.com>","Date":"Thu, 14 Sep 2017 15:16:29 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-version":"1.0","In-reply-to":"<20170914115323.GA1850@amd>","Content-type":"text/plain; charset=\"windows-1252\"; format=\"flowed\"","Content-language":"en-GB","Content-transfer-encoding":"7bit","X-Brightmail-Tracker":["H4sIAAAAAAAAA01Se0hTYRzlu7svzeVtLv2pkDEoyphpRl3LRCPi9qAXPbT+qJEXC52OTSV7\n\tMTV8TFuKJbrETCrURMdysi3tsZqWkrTCosy0iKJMjUqnRTPcneB/53znnO9wPj5aJHlIhNAn\n\t0zN5dboiTUb64u2PVkbKo3NtSZH2PIK99riPYHsqPmPsgNmIs8XlNyjW/L0FsaVGM8F2V+oJ\n\tdrDHQbIzHRaK/dk2ibG9dzPjF3BWwyDFXS2qJjhTUzHJ1T7dy3156SK5htsuivtlWsL1TPyi\n\t9tCHfWOT+bST2bx6ddwx3xOdtw6q3P6nhlxGTIsKxTrkQwOzFpwfR5CAA+H5+1ZSh3xpCWNB\n\tcPn3JBKIC4F56jM5l3A7r4gEwYigb6bfS4YQ3Mwt8LgCGDl0ugepWSxlwsCsb/CYRIwJgzHD\n\tBWxWIJkouOjQe8rFTBzop4c9AZxZBuUlvR7PYiYR2l1VpOBZBFMV73EdomkfZgW01ATPHouY\n\tBBiutxICDoKuoTdIwGFwp3nU0wtMPgVa+wQlTNgCH+//wAQcAN+626jZO4EJhReOTYL/EoIn\n\tzflIIFUI3hWWeQMb4VG309u2EMYmSgkhLIaiAolg4aBj4Bku4ASwGvK8j1qJwzuHjSpDYYZ5\n\tewzzRhjmjTDMG1GH8CYUyKs0yhReE6WKjtAolJqs9JSI4xlKE/J8rPD1FmTs22lHDI1kfuLh\n\tGGuShFBka3KUdgS0SCYV63JsSRJxsiLnNK/OOKrOSuM1dhRK47IgcWDrq0QJk6LI5FN5XsWr\n\t51SM9gnRoh1xdap6p4l1+8cfqdhmlW+VLiUbp0ZNSqV0H3ZmnaNmPKZTnaq9cdoH301lBmVX\n\tlO8oWfOjzfHJb/zAdrn669nN0r6uD7/7S1fljJfEPnbWvu4fbGisOqR4vQFLtKUGnyvo3984\n\tklsX/UXbVL38z71dCSGW63/Ptz1ofeuebj3zT4ZrTiiiwkVqjeI/oarCLVQDAAA=","H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42I5/e+xoK5R465Ig73vjS3mHznHanFq8jMm\n\ti9tbN7BYdE5cwm6x9c06RoueDVtZLY5P62O1uHvqKJvF/z072C0+bfnGZHF6d4kDt8fOWXfZ\n\tPWZ3zGT12LSqk81j3slAj+eXv7N5rFj9nd3j8yY5j1NfP7MHcERx2aSk5mSWpRbp2yVwZexd\n\tFlbwj7/i/vcNTA2M7bxdjJwcEgImEv8uTmXuYuTiEBJYxyixYtZzdgjnIaPEko9LWUCqhAV0\n\tJfb+u8sOYosIyEts7VsB1sEssIlJYu+qM2wQHX0sEkvmd7OBVLEJGEr0Hu1jBLF5Bewk+n4+\n\tAOtmEVCVmNh9mgnEFhWIkOh7e5kdokZQ4sfke0DbODg4BTQk1s2RBAkzC9hKLHi/jgXCFpc4\n\tdv8mI4QtL7F5zVvmCYwCs5B0z0LSMgtJyywkLQsYWVYxSqYWFOem5xYbFRjmpZbrFSfmFpfm\n\tpesl5+duYgRG0rbDWn07GO8viT/EKMDBqMTD+8ByZ6QQa2JZcWXuIUYJDmYlEd6uyl2RQrwp\n\tiZVVqUX58UWlOanFhxilOViUxHkz+2ZECgmkJ5akZqemFqQWwWSZODilGhij5GrsOI7YHmC4\n\t8/hXkcab5YpZ5+YeONFZtKGJdXF2+YZUEV2PVtm7bFcfrzcNuRj0ZK/Qdb6Hri+MpsQL23+L\n\tCDe+PO/praSYBdMWFbNln1RMCPzu3+bCcuFZ9qk0fuGYSSdzXh63PHhiLW+OfvDmT+c/vfx6\n\t5ocSQ43B6YQrky3+/1LLYy9VYinOSDTUYi4qTgQAZkDuaqACAAA="],"X-CMS-MailID":"20170914131634epcas1p363f283150d0d4dc43bc6072d1e691f9b","X-Msg-Generator":"CA","X-Sender-IP":"182.195.42.142","X-Local-Sender":"=?utf-8?q?Sylwester_Nawrocki=1BSRPOL-Kernel_=28TP=29=1B?=\n\t=?utf-8?b?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?=","X-Global-Sender":"=?utf-8?q?Sylwester_Nawrocki=1BSRPOL-Kernel_=28TP=29=1BS?=\n\t=?utf-8?q?amsung_Electronics=1BSenior_Software_Engineer?=","X-Sender-Code":"=?utf-8?q?C10=1BEHQ=1BC10CD02CD027392?=","CMS-TYPE":"101P","X-CMS-RootMailID":"20170914092415epcas2p26c049a698851778673034c16afb290b9","X-RootMTR":"20170914092415epcas2p26c049a698851778673034c16afb290b9","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>\n\t<20170912215529.GA17218@amd>\n\t<21824758-28a1-7007-6db5-86a900025d14@gmail.com>\n\t\n\t<4bf12e8e-beff-0199-cdee-4a52ebe7cdaf@samsung.com>\n\t<20170914100718.GA3843@amd>\n\t<1f34a891-edb1-251c-86a8-ba4a90c485d3@samsung.com>\n\t<20170914115323.GA1850@amd>","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1770034,"web_url":"http://patchwork.ozlabs.org/comment/1770034/","msgid":"<20170918091204.245dewmyruxtfhyb@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-18T09:12:04","subject":"Re: as3645a flash userland interface","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Hi Jacek,\n\nOn Tue, Sep 12, 2017 at 08:53:33PM +0200, Jacek Anaszewski wrote:\n> Hi Pavel,\n> \n> On 09/12/2017 12:36 PM, Pavel Machek wrote:\n> > Hi!\n> > \n> > There were some changes to as3645a flash controller. Before we have\n> > stable interface we have to keep forever I want to ask:\n> \n> Note that we have already two LED flash class drivers - leds-max77693\n> and leds-aat1290. They have been present in mainline for over two years\n> now.\n> \n> > What directory are the flash controls in?\n> > \n> > /sys/class/leds/led-controller:flash ?\n> > \n> > Could we arrange for something less generic, like\n> > \n> > /sys/class/leds/main-camera:flash ?\n> \n> I'd rather avoid overcomplicating this. LED class device name pattern\n> is well defined to devicename:colour:function\n> (see Documentation/leds/leds-class.txt, \"LED Device Naming\" section).\n> \n> In this case \"flash\" in place of the \"function\" segment makes the\n> things clear enough I suppose.\n\nOh. I have to admit I've completely missed this. :-o\n\nI'll address this in v2 of the as3645a fixes, plus submit related V4L2\nflash class documentation fixes a little later.","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 3xwhBZ1GM4z9s7M\n\tfor ;\n\tMon, 18 Sep 2017 19:52:38 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753772AbdIRJMK (ORCPT\n\t);\n\tMon, 18 Sep 2017 05:12:10 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:44056 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1753748AbdIRJMH (ORCPT\n\t); Mon, 18 Sep 2017 05:12:07 -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 10A8860131;\n\tMon, 18 Sep 2017 12:12:05 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from )\n\tid 1dts60-0004pV-IX; Mon, 18 Sep 2017 12:12:04 +0300"],"Date":"Mon, 18 Sep 2017 12:12:04 +0300","From":"Sakari Ailus ","To":"Jacek Anaszewski ","Cc":"Pavel Machek , Sakari Ailus ,\n\tlinux-leds@vger.kernel.org, linux-media@vger.kernel.org,\n\tniklas.soderlund@ragnatech.se, robh@kernel.org, hverkuil@xs4all.nl,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org,\n\tsre@kernel.org","Subject":"Re: as3645a flash userland interface","Message-ID":"<20170918091204.245dewmyruxtfhyb@valkosipuli.retiisi.org.uk>","References":"<20170912084236.1154-1-sakari.ailus@linux.intel.com>\n\t<20170912084236.1154-25-sakari.ailus@linux.intel.com>\n\t<20170912103628.GB27117@amd>\n\t<7b679cb3-ce58-e1d1-60bf-995896bf46eb@gmail.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<7b679cb3-ce58-e1d1-60bf-995896bf46eb@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"}}]