[{"id":1761584,"web_url":"http://patchwork.ozlabs.org/comment/1761584/","msgid":"<7191ed9e-0fa8-cbc3-ebab-178ce8a0b8bc@xs4all.nl>","list_archive_url":null,"date":"2017-09-01T10:45:51","subject":"Re: [PATCH v6 1/5] v4l: fwnode: Move KernelDoc documentation to the\n\theader","submitter":{"id":723,"url":"http://patchwork.ozlabs.org/api/people/723/","name":"Hans Verkuil","email":"hverkuil@xs4all.nl"},"content":"On 30/08/17 13:49, Sakari Ailus wrote:\n> In V4L2 the practice is to have the KernelDoc documentation in the header\n> and not in .c source code files. This consequientally makes the V4L2\n> fwnode function documentation part of the Media documentation build.\n> \n> Also correct the link related function and argument naming in\n> documentation.\n> \n> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>\n> Reviewed-by: Niklas SÃ¶derlund <niklas.soderlund+renesas@ragnatech.se>\n\nAcked-by: Hans Verkuil <hans.verkuil@cisco.com>\n\nRegards,\n\n\tHans\n\n> ---\n>  drivers/media/v4l2-core/v4l2-fwnode.c | 75 --------------------------------\n>  include/media/v4l2-fwnode.h           | 81 ++++++++++++++++++++++++++++++++++-\n>  2 files changed, 80 insertions(+), 76 deletions(-)\n> \n> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c\n> index 40b2fbfe8865..706f9e7b90f1 100644\n> --- a/drivers/media/v4l2-core/v4l2-fwnode.c\n> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c\n> @@ -181,25 +181,6 @@ v4l2_fwnode_endpoint_parse_csi1_bus(struct fwnode_handle *fwnode,\n>  \t\tvep->bus_type = V4L2_MBUS_CSI1;\n>  }\n>  \n> -/**\n> - * v4l2_fwnode_endpoint_parse() - parse all fwnode node properties\n> - * @fwnode: pointer to the endpoint's fwnode handle\n> - * @vep: pointer to the V4L2 fwnode data structure\n> - *\n> - * All properties are optional. If none are found, we don't set any flags. This\n> - * means the port has a static configuration and no properties have to be\n> - * specified explicitly. If any properties that identify the bus as parallel\n> - * are found and slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if\n> - * we recognise the bus as serial CSI-2 and clock-noncontinuous isn't set, we\n> - * set the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag. The caller should hold a\n> - * reference to @fwnode.\n> - *\n> - * NOTE: This function does not parse properties the size of which is variable\n> - * without a low fixed limit. Please use v4l2_fwnode_endpoint_alloc_parse() in\n> - * new drivers instead.\n> - *\n> - * Return: 0 on success or a negative error code on failure.\n> - */\n>  int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwnode,\n>  \t\t\t       struct v4l2_fwnode_endpoint *vep)\n>  {\n> @@ -239,14 +220,6 @@ int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwnode,\n>  }\n>  EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_parse);\n>  \n> -/*\n> - * v4l2_fwnode_endpoint_free() - free the V4L2 fwnode acquired by\n> - * v4l2_fwnode_endpoint_alloc_parse()\n> - * @vep - the V4L2 fwnode the resources of which are to be released\n> - *\n> - * It is safe to call this function with NULL argument or on a V4L2 fwnode the\n> - * parsing of which failed.\n> - */\n>  void v4l2_fwnode_endpoint_free(struct v4l2_fwnode_endpoint *vep)\n>  {\n>  \tif (IS_ERR_OR_NULL(vep))\n> @@ -257,29 +230,6 @@ void v4l2_fwnode_endpoint_free(struct v4l2_fwnode_endpoint *vep)\n>  }\n>  EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_free);\n>  \n> -/**\n> - * v4l2_fwnode_endpoint_alloc_parse() - parse all fwnode node properties\n> - * @fwnode: pointer to the endpoint's fwnode handle\n> - *\n> - * All properties are optional. If none are found, we don't set any flags. This\n> - * means the port has a static configuration and no properties have to be\n> - * specified explicitly. If any properties that identify the bus as parallel\n> - * are found and slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if\n> - * we recognise the bus as serial CSI-2 and clock-noncontinuous isn't set, we\n> - * set the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag. The caller should hold a\n> - * reference to @fwnode.\n> - *\n> - * v4l2_fwnode_endpoint_alloc_parse() has two important differences to\n> - * v4l2_fwnode_endpoint_parse():\n> - *\n> - * 1. It also parses variable size data.\n> - *\n> - * 2. The memory it has allocated to store the variable size data must be freed\n> - *    using v4l2_fwnode_endpoint_free() when no longer needed.\n> - *\n> - * Return: Pointer to v4l2_fwnode_endpoint if successful, on an error pointer\n> - * on error.\n> - */\n>  struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(\n>  \tstruct fwnode_handle *fwnode)\n>  {\n> @@ -322,24 +272,6 @@ struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(\n>  }\n>  EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_alloc_parse);\n>  \n> -/**\n> - * v4l2_fwnode_endpoint_parse_link() - parse a link between two endpoints\n> - * @__fwnode: pointer to the endpoint's fwnode at the local end of the link\n> - * @link: pointer to the V4L2 fwnode link data structure\n> - *\n> - * Fill the link structure with the local and remote nodes and port numbers.\n> - * The local_node and remote_node fields are set to point to the local and\n> - * remote port's parent nodes respectively (the port parent node being the\n> - * parent node of the port node if that node isn't a 'ports' node, or the\n> - * grand-parent node of the port node otherwise).\n> - *\n> - * A reference is taken to both the local and remote nodes, the caller must use\n> - * v4l2_fwnode_endpoint_put_link() to drop the references when done with the\n> - * link.\n> - *\n> - * Return: 0 on success, or -ENOLINK if the remote endpoint fwnode can't be\n> - * found.\n> - */\n>  int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,\n>  \t\t\t   struct v4l2_fwnode_link *link)\n>  {\n> @@ -374,13 +306,6 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,\n>  }\n>  EXPORT_SYMBOL_GPL(v4l2_fwnode_parse_link);\n>  \n> -/**\n> - * v4l2_fwnode_put_link() - drop references to nodes in a link\n> - * @link: pointer to the V4L2 fwnode link data structure\n> - *\n> - * Drop references to the local and remote nodes in the link. This function\n> - * must be called on every link parsed with v4l2_fwnode_parse_link().\n> - */\n>  void v4l2_fwnode_put_link(struct v4l2_fwnode_link *link)\n>  {\n>  \tfwnode_handle_put(link->local_node);\n> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h\n> index 7adec9851d9e..68eb22ba571b 100644\n> --- a/include/media/v4l2-fwnode.h\n> +++ b/include/media/v4l2-fwnode.h\n> @@ -113,13 +113,92 @@ struct v4l2_fwnode_link {\n>  \tunsigned int remote_port;\n>  };\n>  \n> +/**\n> + * v4l2_fwnode_endpoint_parse() - parse all fwnode node properties\n> + * @fwnode: pointer to the endpoint's fwnode handle\n> + * @vep: pointer to the V4L2 fwnode data structure\n> + *\n> + * All properties are optional. If none are found, we don't set any flags. This\n> + * means the port has a static configuration and no properties have to be\n> + * specified explicitly. If any properties that identify the bus as parallel\n> + * are found and slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if\n> + * we recognise the bus as serial CSI-2 and clock-noncontinuous isn't set, we\n> + * set the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag. The caller should hold a\n> + * reference to @fwnode.\n> + *\n> + * NOTE: This function does not parse properties the size of which is variable\n> + * without a low fixed limit. Please use v4l2_fwnode_endpoint_alloc_parse() in\n> + * new drivers instead.\n> + *\n> + * Return: 0 on success or a negative error code on failure.\n> + */\n>  int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwnode,\n>  \t\t\t       struct v4l2_fwnode_endpoint *vep);\n> +\n> +/*\n> + * v4l2_fwnode_endpoint_free() - free the V4L2 fwnode acquired by\n> + * v4l2_fwnode_endpoint_alloc_parse()\n> + * @vep - the V4L2 fwnode the resources of which are to be released\n> + *\n> + * It is safe to call this function with NULL argument or on a V4L2 fwnode the\n> + * parsing of which failed.\n> + */\n> +void v4l2_fwnode_endpoint_free(struct v4l2_fwnode_endpoint *vep);\n> +\n> +/**\n> + * v4l2_fwnode_endpoint_alloc_parse() - parse all fwnode node properties\n> + * @fwnode: pointer to the endpoint's fwnode handle\n> + *\n> + * All properties are optional. If none are found, we don't set any flags. This\n> + * means the port has a static configuration and no properties have to be\n> + * specified explicitly. If any properties that identify the bus as parallel\n> + * are found and slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if\n> + * we recognise the bus as serial CSI-2 and clock-noncontinuous isn't set, we\n> + * set the V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag. The caller should hold a\n> + * reference to @fwnode.\n> + *\n> + * v4l2_fwnode_endpoint_alloc_parse() has two important differences to\n> + * v4l2_fwnode_endpoint_parse():\n> + *\n> + * 1. It also parses variable size data.\n> + *\n> + * 2. The memory it has allocated to store the variable size data must be freed\n> + *    using v4l2_fwnode_endpoint_free() when no longer needed.\n> + *\n> + * Return: Pointer to v4l2_fwnode_endpoint if successful, on an error pointer\n> + * on error.\n> + */\n>  struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(\n>  \tstruct fwnode_handle *fwnode);\n> -void v4l2_fwnode_endpoint_free(struct v4l2_fwnode_endpoint *vep);\n> +\n> +/**\n> + * v4l2_fwnode_parse_link() - parse a link between two endpoints\n> + * @fwnode: pointer to the endpoint's fwnode at the local end of the link\n> + * @link: pointer to the V4L2 fwnode link data structure\n> + *\n> + * Fill the link structure with the local and remote nodes and port numbers.\n> + * The local_node and remote_node fields are set to point to the local and\n> + * remote port's parent nodes respectively (the port parent node being the\n> + * parent node of the port node if that node isn't a 'ports' node, or the\n> + * grand-parent node of the port node otherwise).\n> + *\n> + * A reference is taken to both the local and remote nodes, the caller must use\n> + * v4l2_fwnode_put_link() to drop the references when done with the\n> + * link.\n> + *\n> + * Return: 0 on success, or -ENOLINK if the remote endpoint fwnode can't be\n> + * found.\n> + */\n>  int v4l2_fwnode_parse_link(struct fwnode_handle *fwnode,\n>  \t\t\t   struct v4l2_fwnode_link *link);\n> +\n> +/**\n> + * v4l2_fwnode_put_link() - drop references to nodes in a link\n> + * @link: pointer to the V4L2 fwnode link data structure\n> + *\n> + * Drop references to the local and remote nodes in the link. This function\n> + * must be called on every link parsed with v4l2_fwnode_parse_link().\n> + */\n>  void v4l2_fwnode_put_link(struct v4l2_fwnode_link *link);\n>  \n>  #endif /* _V4L2_FWNODE_H */\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":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkG9z5P7lz9sMN\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tFri,  1 Sep 2017 20:45:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751920AbdIAKp6 (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tFri, 1 Sep 2017 06:45:58 -0400","from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:32803 \"EHLO\n\tlb3-smtp-cloud8.xs4all.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751825AbdIAKp5 (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Fri, 1 Sep 2017 06:45:57 -0400","from [192.168.1.10] ([80.101.105.217])\n\tby smtp-cloud8.xs4all.net with ESMTPA\n\tid njSRd1tRkcQyLnjSSdCI8G; Fri, 01 Sep 2017 12:45:55 +0200"],"Subject":"Re: [PATCH v6 1/5] v4l: fwnode: Move KernelDoc documentation to the\n\theader","To":"Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<20170830114946.17743-2-sakari.ailus@linux.intel.com>","Cc":"niklas.soderlund@ragnatech.se, robh@kernel.org,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org","From":"Hans Verkuil <hverkuil@xs4all.nl>","Message-ID":"<7191ed9e-0fa8-cbc3-ebab-178ce8a0b8bc@xs4all.nl>","Date":"Fri, 1 Sep 2017 12:45:51 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.1","MIME-Version":"1.0","In-Reply-To":"<20170830114946.17743-2-sakari.ailus@linux.intel.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"8bit","X-CMAE-Envelope":"MS4wfLaNcX464rJdQ2deP7a4UpLPxsRXzbtXugbvgAWhbbwT5ojIOV4upxd7Skhs4eF/v4L1vmn2nBiUIoFGvJkwpQUiQo2SX2Mt0RLYE/x209yUpJPb8fom\n\tz08BAnPzMACTbE15uK2Nz3QGMTZ09P3Dm46tU6V7NvMjotaFEUPxhiL1jkIgOxZCmHdj+OO+UK33ecoWv7PGcsOiLE0x+TxATE53SulejAS7/JgY7UarXYB2\n\tEk4nXrI4sqVajfOqAFhFt2p1niFzTvxxiK6ZSSlval8aA5Bp8hAVtR0umVn1zdCDUQf7j2zcdv2jjVWUFcYvGCRvbBHDlFjNzWwsxDH4pWTNkxcKh9LyFTpS\n\tA1YIPu9r7KNfoK3DpG6vV8LgJqBtiQ1MI1S0C6TdS9YUh2zWs6k=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1761585,"web_url":"http://patchwork.ozlabs.org/comment/1761585/","msgid":"<19202cd6-c2fd-36c9-ae04-7cdee541c5f7@xs4all.nl>","list_archive_url":null,"date":"2017-09-01T10:46:05","subject":"Re: [PATCH v6 2/5] v4l: async: Add V4L2 async documentation to the\n\tdocumentation build","submitter":{"id":723,"url":"http://patchwork.ozlabs.org/api/people/723/","name":"Hans Verkuil","email":"hverkuil@xs4all.nl"},"content":"On 30/08/17 13:49, Sakari Ailus wrote:\n> The V4L2 async wasn't part of the documentation build. Fix this.\n> \n> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>\n> Reviewed-by: Niklas SÃ¶derlund <niklas.soderlund+renesas@ragnatech.se>\n\nAcked-by: Hans Verkuil <hans.verkuil@cisco.com>\n\nRegards,\n\n\tHans\n\n\n> ---\n>  Documentation/media/kapi/v4l2-async.rst | 3 +++\n>  Documentation/media/kapi/v4l2-core.rst  | 1 +\n>  2 files changed, 4 insertions(+)\n>  create mode 100644 Documentation/media/kapi/v4l2-async.rst\n> \n> diff --git a/Documentation/media/kapi/v4l2-async.rst b/Documentation/media/kapi/v4l2-async.rst\n> new file mode 100644\n> index 000000000000..523ff9eb09a0\n> --- /dev/null\n> +++ b/Documentation/media/kapi/v4l2-async.rst\n> @@ -0,0 +1,3 @@\n> +V4L2 async kAPI\n> +^^^^^^^^^^^^^^^\n> +.. kernel-doc:: include/media/v4l2-async.h\n> diff --git a/Documentation/media/kapi/v4l2-core.rst b/Documentation/media/kapi/v4l2-core.rst\n> index c7434f38fd9c..5cf292037a48 100644\n> --- a/Documentation/media/kapi/v4l2-core.rst\n> +++ b/Documentation/media/kapi/v4l2-core.rst\n> @@ -19,6 +19,7 @@ Video4Linux devices\n>      v4l2-mc\n>      v4l2-mediabus\n>      v4l2-mem2mem\n> +    v4l2-async\n>      v4l2-fwnode\n>      v4l2-rect\n>      v4l2-tuner\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":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkGB96L3mz9t32\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tFri,  1 Sep 2017 20:46:09 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751825AbdIAKqI (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tFri, 1 Sep 2017 06:46:08 -0400","from lb1-smtp-cloud8.xs4all.net ([194.109.24.21]:50194 \"EHLO\n\tlb1-smtp-cloud8.xs4all.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1752005AbdIAKqH (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Fri, 1 Sep 2017 06:46:07 -0400","from [192.168.1.10] ([80.101.105.217])\n\tby smtp-cloud8.xs4all.net with ESMTPA\n\tid njSfd1tZocQyLnjSgdCID9; Fri, 01 Sep 2017 12:46:06 +0200"],"Subject":"Re: [PATCH v6 2/5] v4l: async: Add V4L2 async documentation to the\n\tdocumentation build","To":"Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<20170830114946.17743-3-sakari.ailus@linux.intel.com>","Cc":"niklas.soderlund@ragnatech.se, robh@kernel.org,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org","From":"Hans Verkuil <hverkuil@xs4all.nl>","Message-ID":"<19202cd6-c2fd-36c9-ae04-7cdee541c5f7@xs4all.nl>","Date":"Fri, 1 Sep 2017 12:46:05 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.1","MIME-Version":"1.0","In-Reply-To":"<20170830114946.17743-3-sakari.ailus@linux.intel.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"8bit","X-CMAE-Envelope":"MS4wfF+7YUPkI73iNKOnM8XaGXV8U/3AwJYJv0d5wPYikjQj2PP/iQBL8xXNURNsX46WCpT882v/o7hnqf7DQaDygAa9JWDAgVYyLdtaEti05yOURkjWGoNQ\n\tl9kMxIm8f+AfbB7KKxpoljygPsCkzi9K4qSpoLHGtxS1/De2hAdCMtk6XlIGuHpd4gdpfZ2vbv07yyawbfNDvFGpnCsEtVIDcpZU6OWMw9zjRgmrdmW6so80\n\tJbS+vN6QXsFU+Gz03pudOIXFzcBxYV83N6e8UI7BKEKbvyLQQmkPagXxLx8n0ELQguHfvUcJKAol5jmCP3MLpmqXjlDZ2RaaAGbacFWKCNv1hlz5rcEed1Ne\n\tCJy7QCSL37c15C8/5K4CiZusZYykr6/SGcFmXTIDXQyFMzuqge8=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1761586,"web_url":"http://patchwork.ozlabs.org/comment/1761586/","msgid":"<7fdb19c5-331e-39f3-adb4-3c6fdeafbbda@xs4all.nl>","list_archive_url":null,"date":"2017-09-01T10:46:18","subject":"Re: [PATCH v6 3/5] docs-rst: v4l: Include Qualcomm CAMSS in\n\tdocumentation build","submitter":{"id":723,"url":"http://patchwork.ozlabs.org/api/people/723/","name":"Hans Verkuil","email":"hverkuil@xs4all.nl"},"content":"On 30/08/17 13:49, Sakari Ailus wrote:\n> Qualcomm CAMSS was left out from documentation build. Fix this.\n> \n> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>\n> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>\n\nAcked-by: Hans Verkuil <hans.verkuil@cisco.com>\n\nRegards,\n\n\tHans\n\n\n> ---\n>  Documentation/media/v4l-drivers/index.rst | 1 +\n>  1 file changed, 1 insertion(+)\n> \n> diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst\n> index 10f2ce42ece2..5c202e23616b 100644\n> --- a/Documentation/media/v4l-drivers/index.rst\n> +++ b/Documentation/media/v4l-drivers/index.rst\n> @@ -50,6 +50,7 @@ For more details see the file COPYING in the source distribution of Linux.\n>  \tphilips\n>  \tpvrusb2\n>  \tpxa_camera\n> +\tqcom_camss\n>  \tradiotrack\n>  \trcar-fdp1\n>  \tsaa7134\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":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkGBP5rWWz9sMN\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tFri,  1 Sep 2017 20:46:21 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751913AbdIAKqU (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tFri, 1 Sep 2017 06:46:20 -0400","from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:32803 \"EHLO\n\tlb3-smtp-cloud8.xs4all.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751864AbdIAKqU (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Fri, 1 Sep 2017 06:46:20 -0400","from [192.168.1.10] ([80.101.105.217])\n\tby smtp-cloud8.xs4all.net with ESMTPA\n\tid njSsd1tgRcQyLnjStdCIGn; Fri, 01 Sep 2017 12:46:19 +0200"],"Subject":"Re: [PATCH v6 3/5] docs-rst: v4l: Include Qualcomm CAMSS in\n\tdocumentation build","To":"Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<20170830114946.17743-4-sakari.ailus@linux.intel.com>","Cc":"niklas.soderlund@ragnatech.se, robh@kernel.org,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org","From":"Hans Verkuil <hverkuil@xs4all.nl>","Message-ID":"<7fdb19c5-331e-39f3-adb4-3c6fdeafbbda@xs4all.nl>","Date":"Fri, 1 Sep 2017 12:46:18 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.1","MIME-Version":"1.0","In-Reply-To":"<20170830114946.17743-4-sakari.ailus@linux.intel.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"7bit","X-CMAE-Envelope":"MS4wfD7/f0m4h+tCMLi9VG+a/8RUHTs0LXshtt32Pm6y6qmlDQXFt1to8OyePzGVQJKyDSJqRO4OET2yPryuKSnqv5y1pi+8CGA30ZbodDwUzAQc+rciVhC3\n\tAvmYqil2YI9Anvk+xdWThhrka+x5CxOPXx1WxBuQMgEuf3HuWXB/vlrbz8+QGx8NyfyS7wN5qizTXXD/0d4Pf9plQWhi1w2FVAwUR6dPZI9/L9YuWi9X8dJG\n\tzTdtxMhaW/+6C6THrGUQoJC8g8Y5gI9B/FQGjnBKamqaPtJQ7LlF//lA+UCru8wXjjr1q7O7tmwgor5ViR8YijXjxFMj7Ao5WTNkLrGPSMcqzPUQS0xWS9km\n\t0Zi6c0GX1pUUl63/MNRY+xqxhjopQ1rTtN+GwSVPqc9yw5OqpEs=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1761600,"web_url":"http://patchwork.ozlabs.org/comment/1761600/","msgid":"<95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>","list_archive_url":null,"date":"2017-09-01T11:28:40","subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","submitter":{"id":723,"url":"http://patchwork.ozlabs.org/api/people/723/","name":"Hans Verkuil","email":"hverkuil@xs4all.nl"},"content":"On 30/08/17 13:49, Sakari Ailus wrote:\n> This is the preferred way to parse the endpoints.\n> \n> Comment rcar-vin as an example.\n> \n> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>\n> ---\n>  drivers/media/platform/rcar-vin/rcar-core.c | 111 ++++++++--------------------\n>  drivers/media/platform/rcar-vin/rcar-dma.c  |  10 +--\n>  drivers/media/platform/rcar-vin/rcar-v4l2.c |  14 ++--\n>  drivers/media/platform/rcar-vin/rcar-vin.h  |   4 +-\n>  drivers/media/v4l2-core/v4l2-fwnode.c       |  47 ++++++++++++\n>  include/media/v4l2-fwnode.h                 |  49 ++++++++++++\n>  6 files changed, 142 insertions(+), 93 deletions(-)\n> \n> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c\n> index 142de447aaaa..4378806be1d4 100644\n> --- a/drivers/media/platform/rcar-vin/rcar-core.c\n> +++ b/drivers/media/platform/rcar-vin/rcar-core.c\n> @@ -21,6 +21,7 @@\n>  #include <linux/platform_device.h>\n>  #include <linux/pm_runtime.h>\n>  \n> +#include <media/v4l2-async.h>\n>  #include <media/v4l2-fwnode.h>\n>  \n>  #include \"rcar-vin.h\"\n> @@ -77,14 +78,14 @@ static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)\n>  \tint ret;\n>  \n>  \t/* Verify subdevices mbus format */\n> -\tif (!rvin_mbus_supported(&vin->digital)) {\n> +\tif (!rvin_mbus_supported(vin->digital)) {\n>  \t\tvin_err(vin, \"Unsupported media bus format for %s\\n\",\n> -\t\t\tvin->digital.subdev->name);\n> +\t\t\tvin->digital->subdev->name);\n>  \t\treturn -EINVAL;\n>  \t}\n>  \n>  \tvin_dbg(vin, \"Found media bus format for %s: %d\\n\",\n> -\t\tvin->digital.subdev->name, vin->digital.code);\n> +\t\tvin->digital->subdev->name, vin->digital->code);\n>  \n>  \tret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);\n>  \tif (ret < 0) {\n> @@ -103,7 +104,7 @@ static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,\n>  \n>  \tvin_dbg(vin, \"unbind digital subdev %s\\n\", subdev->name);\n>  \trvin_v4l2_remove(vin);\n> -\tvin->digital.subdev = NULL;\n> +\tvin->digital->subdev = NULL;\n>  }\n>  \n>  static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,\n> @@ -120,117 +121,67 @@ static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,\n>  \tret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);\n>  \tif (ret < 0)\n>  \t\treturn ret;\n> -\tvin->digital.source_pad = ret;\n> +\tvin->digital->source_pad = ret;\n>  \n>  \tret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);\n> -\tvin->digital.sink_pad = ret < 0 ? 0 : ret;\n> +\tvin->digital->sink_pad = ret < 0 ? 0 : ret;\n>  \n> -\tvin->digital.subdev = subdev;\n> +\tvin->digital->subdev = subdev;\n>  \n>  \tvin_dbg(vin, \"bound subdev %s source pad: %u sink pad: %u\\n\",\n> -\t\tsubdev->name, vin->digital.source_pad,\n> -\t\tvin->digital.sink_pad);\n> +\t\tsubdev->name, vin->digital->source_pad,\n> +\t\tvin->digital->sink_pad);\n>  \n>  \treturn 0;\n>  }\n>  \n> -static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,\n> -\t\t\t\t    struct device_node *ep,\n> -\t\t\t\t    struct v4l2_mbus_config *mbus_cfg)\n> +static int rvin_digital_parse_v4l2(struct device *dev,\n> +\t\t\t\t   struct v4l2_fwnode_endpoint *vep,\n> +\t\t\t\t   struct v4l2_async_subdev *asd)\n>  {\n> -\tstruct v4l2_fwnode_endpoint v4l2_ep;\n> -\tint ret;\n> -\n> -\tret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &v4l2_ep);\n> -\tif (ret) {\n> -\t\tvin_err(vin, \"Could not parse v4l2 endpoint\\n\");\n> -\t\treturn -EINVAL;\n> -\t}\n> +\tstruct rvin_dev *vin = dev_get_drvdata(dev);\n> +\tstruct rvin_graph_entity *rvge =\n> +\t\tcontainer_of(asd, struct rvin_graph_entity, asd);\n>  \n> -\tmbus_cfg->type = v4l2_ep.bus_type;\n> +\trvge->mbus_cfg.type = vep->bus_type;\n>  \n> -\tswitch (mbus_cfg->type) {\n> +\tswitch (rvge->mbus_cfg.type) {\n>  \tcase V4L2_MBUS_PARALLEL:\n>  \t\tvin_dbg(vin, \"Found PARALLEL media bus\\n\");\n> -\t\tmbus_cfg->flags = v4l2_ep.bus.parallel.flags;\n> +\t\trvge->mbus_cfg.flags = vep->bus.parallel.flags;\n>  \t\tbreak;\n>  \tcase V4L2_MBUS_BT656:\n>  \t\tvin_dbg(vin, \"Found BT656 media bus\\n\");\n> -\t\tmbus_cfg->flags = 0;\n> +\t\trvge->mbus_cfg.flags = 0;\n>  \t\tbreak;\n>  \tdefault:\n>  \t\tvin_err(vin, \"Unknown media bus type\\n\");\n>  \t\treturn -EINVAL;\n>  \t}\n>  \n> -\treturn 0;\n> -}\n> -\n> -static int rvin_digital_graph_parse(struct rvin_dev *vin)\n> -{\n> -\tstruct device_node *ep, *np;\n> -\tint ret;\n> -\n> -\tvin->digital.asd.match.fwnode.fwnode = NULL;\n> -\tvin->digital.subdev = NULL;\n> -\n> -\t/*\n> -\t * Port 0 id 0 is local digital input, try to get it.\n> -\t * Not all instances can or will have this, that is OK\n> -\t */\n> -\tep = of_graph_get_endpoint_by_regs(vin->dev->of_node, 0, 0);\n> -\tif (!ep)\n> -\t\treturn 0;\n> -\n> -\tnp = of_graph_get_remote_port_parent(ep);\n> -\tif (!np) {\n> -\t\tvin_err(vin, \"No remote parent for digital input\\n\");\n> -\t\tof_node_put(ep);\n> -\t\treturn -EINVAL;\n> -\t}\n> -\tof_node_put(np);\n> -\n> -\tret = rvin_digitial_parse_v4l2(vin, ep, &vin->digital.mbus_cfg);\n> -\tof_node_put(ep);\n> -\tif (ret)\n> -\t\treturn ret;\n> -\n> -\tvin->digital.asd.match.fwnode.fwnode = of_fwnode_handle(np);\n> -\tvin->digital.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;\n> +\tvin->digital = rvge;\n>  \n>  \treturn 0;\n>  }\n>  \n>  static int rvin_digital_graph_init(struct rvin_dev *vin)\n>  {\n> -\tstruct v4l2_async_subdev **subdevs = NULL;\n>  \tint ret;\n>  \n> -\tret = rvin_digital_graph_parse(vin);\n> +\tret = v4l2_async_notifier_parse_fwnode_endpoint(\n> +\t\tvin->dev, &vin->notifier, 0, 0,\n> +\t\tsizeof(struct rvin_graph_entity), rvin_digital_parse_v4l2);\n>  \tif (ret)\n>  \t\treturn ret;\n>  \n> -\tif (!vin->digital.asd.match.fwnode.fwnode) {\n> -\t\tvin_dbg(vin, \"No digital subdevice found\\n\");\n> -\t\treturn -ENODEV;\n> -\t}\n> -\n> -\t/* Register the subdevices notifier. */\n> -\tsubdevs = devm_kzalloc(vin->dev, sizeof(*subdevs), GFP_KERNEL);\n> -\tif (subdevs == NULL)\n> -\t\treturn -ENOMEM;\n> +\tif (vin->notifier.num_subdevs > 0)\n> +\t\tvin_dbg(vin, \"Found digital subdevice %pOF\\n\",\n> +\t\t\tto_of_node(\n> +\t\t\t\tvin->notifier.subdevs[0]->match.fwnode.fwnode));\n>  \n> -\tsubdevs[0] = &vin->digital.asd;\n> -\n> -\tvin_dbg(vin, \"Found digital subdevice %pOF\\n\",\n> -\t\tto_of_node(subdevs[0]->match.fwnode.fwnode));\n> -\n> -\tvin->notifier.num_subdevs = 1;\n> -\tvin->notifier.subdevs = subdevs;\n>  \tvin->notifier.bound = rvin_digital_notify_bound;\n>  \tvin->notifier.unbind = rvin_digital_notify_unbind;\n>  \tvin->notifier.complete = rvin_digital_notify_complete;\n> -\n>  \tret = v4l2_async_notifier_register(&vin->v4l2_dev, &vin->notifier);\n>  \tif (ret < 0) {\n>  \t\tvin_err(vin, \"Notifier registration failed\\n\");\n> @@ -290,6 +241,8 @@ static int rcar_vin_probe(struct platform_device *pdev)\n>  \tif (ret)\n>  \t\treturn ret;\n>  \n> +\tplatform_set_drvdata(pdev, vin);\n> +\n>  \tret = rvin_digital_graph_init(vin);\n>  \tif (ret < 0)\n>  \t\tgoto error;\n> @@ -297,11 +250,10 @@ static int rcar_vin_probe(struct platform_device *pdev)\n>  \tpm_suspend_ignore_children(&pdev->dev, true);\n>  \tpm_runtime_enable(&pdev->dev);\n>  \n> -\tplatform_set_drvdata(pdev, vin);\n> -\n>  \treturn 0;\n>  error:\n>  \trvin_dma_remove(vin);\n> +\tv4l2_async_notifier_release(&vin->notifier);\n>  \n>  \treturn ret;\n>  }\n> @@ -313,6 +265,7 @@ static int rcar_vin_remove(struct platform_device *pdev)\n>  \tpm_runtime_disable(&pdev->dev);\n>  \n>  \tv4l2_async_notifier_unregister(&vin->notifier);\n> +\tv4l2_async_notifier_release(&vin->notifier);\n>  \n>  \trvin_dma_remove(vin);\n>  \n> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c b/drivers/media/platform/rcar-vin/rcar-dma.c\n> index b136844499f6..23fdff7a7370 100644\n> --- a/drivers/media/platform/rcar-vin/rcar-dma.c\n> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c\n> @@ -183,7 +183,7 @@ static int rvin_setup(struct rvin_dev *vin)\n>  \t/*\n>  \t * Input interface\n>  \t */\n> -\tswitch (vin->digital.code) {\n> +\tswitch (vin->digital->code) {\n>  \tcase MEDIA_BUS_FMT_YUYV8_1X16:\n>  \t\t/* BT.601/BT.1358 16bit YCbCr422 */\n>  \t\tvnmc |= VNMC_INF_YUV16;\n> @@ -191,7 +191,7 @@ static int rvin_setup(struct rvin_dev *vin)\n>  \t\tbreak;\n>  \tcase MEDIA_BUS_FMT_UYVY8_2X8:\n>  \t\t/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */\n> -\t\tvnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?\n> +\t\tvnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?\n>  \t\t\tVNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;\n>  \t\tinput_is_yuv = true;\n>  \t\tbreak;\n> @@ -200,7 +200,7 @@ static int rvin_setup(struct rvin_dev *vin)\n>  \t\tbreak;\n>  \tcase MEDIA_BUS_FMT_UYVY10_2X10:\n>  \t\t/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */\n> -\t\tvnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?\n> +\t\tvnmc |= vin->digital->mbus_cfg.type == V4L2_MBUS_BT656 ?\n>  \t\t\tVNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;\n>  \t\tinput_is_yuv = true;\n>  \t\tbreak;\n> @@ -212,11 +212,11 @@ static int rvin_setup(struct rvin_dev *vin)\n>  \tdmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);\n>  \n>  \t/* Hsync Signal Polarity Select */\n> -\tif (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))\n> +\tif (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))\n>  \t\tdmr2 |= VNDMR2_HPS;\n>  \n>  \t/* Vsync Signal Polarity Select */\n> -\tif (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))\n> +\tif (!(vin->digital->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))\n>  \t\tdmr2 |= VNDMR2_VPS;\n>  \n>  \t/*\n> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c\n> index dd37ea811680..b479b882da12 100644\n> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c\n> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c\n> @@ -111,7 +111,7 @@ static int rvin_reset_format(struct rvin_dev *vin)\n>  \tstruct v4l2_mbus_framefmt *mf = &fmt.format;\n>  \tint ret;\n>  \n> -\tfmt.pad = vin->digital.source_pad;\n> +\tfmt.pad = vin->digital->source_pad;\n>  \n>  \tret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, &fmt);\n>  \tif (ret)\n> @@ -172,13 +172,13 @@ static int __rvin_try_format_source(struct rvin_dev *vin,\n>  \n>  \tsd = vin_to_source(vin);\n>  \n> -\tv4l2_fill_mbus_format(&format.format, pix, vin->digital.code);\n> +\tv4l2_fill_mbus_format(&format.format, pix, vin->digital->code);\n>  \n>  \tpad_cfg = v4l2_subdev_alloc_pad_config(sd);\n>  \tif (pad_cfg == NULL)\n>  \t\treturn -ENOMEM;\n>  \n> -\tformat.pad = vin->digital.source_pad;\n> +\tformat.pad = vin->digital->source_pad;\n>  \n>  \tfield = pix->field;\n>  \n> @@ -555,7 +555,7 @@ static int rvin_enum_dv_timings(struct file *file, void *priv_fh,\n>  \tif (timings->pad)\n>  \t\treturn -EINVAL;\n>  \n> -\ttimings->pad = vin->digital.sink_pad;\n> +\ttimings->pad = vin->digital->sink_pad;\n>  \n>  \tret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);\n>  \n> @@ -607,7 +607,7 @@ static int rvin_dv_timings_cap(struct file *file, void *priv_fh,\n>  \tif (cap->pad)\n>  \t\treturn -EINVAL;\n>  \n> -\tcap->pad = vin->digital.sink_pad;\n> +\tcap->pad = vin->digital->sink_pad;\n>  \n>  \tret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);\n>  \n> @@ -625,7 +625,7 @@ static int rvin_g_edid(struct file *file, void *fh, struct v4l2_edid *edid)\n>  \tif (edid->pad)\n>  \t\treturn -EINVAL;\n>  \n> -\tedid->pad = vin->digital.sink_pad;\n> +\tedid->pad = vin->digital->sink_pad;\n>  \n>  \tret = v4l2_subdev_call(sd, pad, get_edid, edid);\n>  \n> @@ -643,7 +643,7 @@ static int rvin_s_edid(struct file *file, void *fh, struct v4l2_edid *edid)\n>  \tif (edid->pad)\n>  \t\treturn -EINVAL;\n>  \n> -\tedid->pad = vin->digital.sink_pad;\n> +\tedid->pad = vin->digital->sink_pad;\n>  \n>  \tret = v4l2_subdev_call(sd, pad, set_edid, edid);\n>  \n> diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h b/drivers/media/platform/rcar-vin/rcar-vin.h\n> index 9bfb5a7c4dc4..5382078143fb 100644\n> --- a/drivers/media/platform/rcar-vin/rcar-vin.h\n> +++ b/drivers/media/platform/rcar-vin/rcar-vin.h\n> @@ -126,7 +126,7 @@ struct rvin_dev {\n>  \tstruct v4l2_device v4l2_dev;\n>  \tstruct v4l2_ctrl_handler ctrl_handler;\n>  \tstruct v4l2_async_notifier notifier;\n> -\tstruct rvin_graph_entity digital;\n> +\tstruct rvin_graph_entity *digital;\n>  \n>  \tstruct mutex lock;\n>  \tstruct vb2_queue queue;\n> @@ -145,7 +145,7 @@ struct rvin_dev {\n>  \tstruct v4l2_rect compose;\n>  };\n>  \n> -#define vin_to_source(vin)\t\tvin->digital.subdev\n> +#define vin_to_source(vin)\t\t((vin)->digital->subdev)\n>  \n>  /* Debug */\n>  #define vin_dbg(d, fmt, arg...)\t\tdev_dbg(d->dev, fmt, ##arg)\n> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c\n> index 2496d76eef4b..4720e8a043cf 100644\n> --- a/drivers/media/v4l2-core/v4l2-fwnode.c\n> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c\n> @@ -444,6 +444,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(\n>  }\n>  EXPORT_SYMBOL_GPL(v4l2_async_notifier_parse_fwnode_endpoints);\n>  \n> +int v4l2_async_notifier_parse_fwnode_endpoint(\n> +\tstruct device *dev, struct v4l2_async_notifier *notifier,\n> +\tunsigned int port_id, unsigned int endpoint_id, size_t asd_struct_size,\n> +\tint (*parse_single)(struct device *dev,\n> +\t\t\t    struct v4l2_fwnode_endpoint *vep,\n> +\t\t\t    struct v4l2_async_subdev *asd))\n> +{\n> +\tstruct fwnode_handle *fwnode = NULL;\n> +\tint ret;\n> +\n> +\twhile ((fwnode = fwnode_graph_get_next_endpoint(\n> +\t\t\tdev_fwnode(dev), fwnode))) {\n> +\t\tstruct fwnode_endpoint ep;\n> +\n> +\t\tret = fwnode_graph_parse_endpoint(fwnode, &ep);\n> +\t\tif (ret < 0)\n> +\t\t\tcontinue;\n> +\n> +\t\tif (!fwnode_device_is_available(\n> +\t\t\t    fwnode_graph_get_port_parent(fwnode)))\n> +\t\t\tcontinue;\n> +\n> +\t\tif (ep.port == port_id && ep.id == endpoint_id)\n> +\t\t\tbreak;\n> +\t}\n> +\n> +\tif (!fwnode)\n> +\t\treturn -ENOENT;\n> +\n> +\tret = v4l2_async_notifier_realloc(notifier, notifier->num_subdevs + 1);\n> +\tif (ret)\n> +\t\tgoto out_err;\n> +\n> +\tret = v4l2_async_notifier_fwnode_parse_endpoint(\n> +\t\tdev, notifier, fwnode, asd_struct_size, parse_single);\n> +\tif (ret)\n> +\t\tgoto out_err;\n> +\n> +\treturn 0;\n> +\n> +out_err:\n> +\tfwnode_handle_put(fwnode);\n> +\n> +\treturn ret;\n> +}\n> +EXPORT_SYMBOL_GPL(v4l2_async_notifier_parse_fwnode_endpoint);\n> +\n>  MODULE_LICENSE(\"GPL\");\n>  MODULE_AUTHOR(\"Sakari Ailus <sakari.ailus@linux.intel.com>\");\n>  MODULE_AUTHOR(\"Sylwester Nawrocki <s.nawrocki@samsung.com>\");\n> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h\n> index d063ab4ff67b..dd13604178b4 100644\n> --- a/include/media/v4l2-fwnode.h\n> +++ b/include/media/v4l2-fwnode.h\n> @@ -249,4 +249,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(\n>  \t\t\t    struct v4l2_fwnode_endpoint *vep,\n>  \t\t\t    struct v4l2_async_subdev *asd));\n>  \n> +/**\n> + * v4l2_async_notifier_parse_fwnode_endpoint - Set up async notifier for an\n> + *\t\t\t\t\t       fwnode based sub-device\n> + * @dev: @struct device pointer\n> + * @notifier: pointer to &struct v4l2_async_notifier\n> + * @port_id: port number\n> + * @endpoint_id: endpoint number\n> + * @asd_struct_size: size of the driver's async sub-device struct, including\n> + *\t\t     sizeof(struct v4l2_async_subdev). The &struct\n> + *\t\t     v4l2_async_subdev shall be the first member of\n> + *\t\t     the driver's async sub-device struct, i.e. both\n> + *\t\t     begin at the same memory address.\n> + * @parse_single: driver's callback function called on each V4L2 fwnode endpoint\n> + *\n> + * Parse the fwnode endpoint of the @dev device corresponding to the given port\n> + * and endpoint numbres and populate the async sub- devices array of the\n\nnumbers\nno space after sub-\n\n> + * notifier. The @parse_endpoint callback function is called for the endpoint\n\nparse_single, but (as in the previous patch) I actually prefer parse_endpoint.\n\n> + * with the corresponding async sub-device pointer to let the caller initialize\n> + * the driver-specific part of the async sub-device structure.\n> + *\n> + * The notifier memory shall be zeroed before this function is called on the\n> + * notifier.\n\nShould it? Doesn't this add additional subdevs?\n\nI'm lost. What's the relationship between v4l2_async_notifier_parse_fwnode_endpoints\nand this function? When do you use which? When you should zero the notifier?\n\nRegards,\n\n\tHans\n\n> + *\n> + * This function may not be called on a registered notifier and may be called on\n> + * a notifier once or more times, but may not be called more than once on a\n> + * given port / endpoint pair. When using this function, the user may not access\n> + * the notifier's subdevs array nor change notifier's num_subdevs field, these\n> + * are reserved for the framework's internal use only.\n> + *\n> + * The @struct v4l2_fwnode_endpoint passed to the callback function\n> + * @parse_single is released once the function is finished. If there is a need\n> + * to retain that configuration, the user needs to allocate memory for it.\n> + *\n> + * Any notifier populated using this function must be released with a call to\n> + * v4l2_async_notifier_release() after it has been unregistered and the async\n> + * sub-devices are no longer in use.\n> + *\n> + * Return: %0 on success, including when no async sub-devices are found\n> + *\t   %-ENOMEM if memory allocation failed\n> + *\t   %-EINVAL if graph or endpoint parsing failed\n> + *\t   Other error codes as returned by @parse_single\n> + */\n> +int v4l2_async_notifier_parse_fwnode_endpoint(\n> +\tstruct device *dev, struct v4l2_async_notifier *notifier,\n> +\tunsigned int port_id, unsigned int endpoint_id, size_t asd_struct_size,\n> +\tint (*parse_single)(struct device *dev,\n> +\t\t\t    struct v4l2_fwnode_endpoint *vep,\n> +\t\t\t    struct v4l2_async_subdev *asd));\n> +\n>  #endif /* _V4L2_FWNODE_H */\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":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkH7L42s9z9sRV\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tFri,  1 Sep 2017 21:28:46 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751895AbdIAL2n (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tFri, 1 Sep 2017 07:28:43 -0400","from lb3-smtp-cloud8.xs4all.net ([194.109.24.29]:37356 \"EHLO\n\tlb3-smtp-cloud8.xs4all.net\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751862AbdIAL2m (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Fri, 1 Sep 2017 07:28:42 -0400","from [192.168.1.10] ([80.101.105.217])\n\tby smtp-cloud8.xs4all.net with ESMTPA\n\tid nk7sd2DnvcQyLnk7tdCTAQ; Fri, 01 Sep 2017 13:28:41 +0200"],"Subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","To":"Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<20170830114946.17743-6-sakari.ailus@linux.intel.com>","Cc":"niklas.soderlund@ragnatech.se, robh@kernel.org,\n\tlaurent.pinchart@ideasonboard.com, devicetree@vger.kernel.org","From":"Hans Verkuil <hverkuil@xs4all.nl>","Message-ID":"<95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>","Date":"Fri, 1 Sep 2017 13:28:40 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101\n\tThunderbird/45.7.1","MIME-Version":"1.0","In-Reply-To":"<20170830114946.17743-6-sakari.ailus@linux.intel.com>","Content-Type":"text/plain; charset=windows-1252","Content-Transfer-Encoding":"7bit","X-CMAE-Envelope":"MS4wfH1hZ6+RmMPdOuKpyWXALS6XHJWJUIymbRVV4/b2JmqYuFczwuvm+6W8OmIx85k9h5J+p+3DI5ZKYb7ZxpZKxnZsvWzpzmErKAiBH7u3x0+iPSEbLV1k\n\twyMJRuU4wRDbI9tO7qRX/Zp7PVtdhZa0uKjsAMblRhf7oRxa607Z4p0hqdEPK9dwTHu11kUAvmoQf4cD3zCQ3v/U2LieXASU5aufBAeZ12QR/nu1E6JaWWn8\n\tAhr+yBVuuiP3MPtUjsT66cf1bMrc6UoEFpyHD4f/21YnAeZCd1r3SMsRLVWNHdoqKqiFpszFeGkyBD7KzcU3kMrbZrdyaaMwm2onmjZW1IgjfE1ab/C4mMb9\n\t2RbYECqKQLPOaul9Iy+1CAMWV48ZdhfPjWPO6yV7Zw9nwTj0y60=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762026,"web_url":"http://patchwork.ozlabs.org/comment/1762026/","msgid":"<20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-01T22:57:48","subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Hi Hans,\n\nThanks for the review.\n\nOn Fri, Sep 01, 2017 at 01:28:40PM +0200, Hans Verkuil wrote:\n> > diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h\n> > index d063ab4ff67b..dd13604178b4 100644\n> > --- a/include/media/v4l2-fwnode.h\n> > +++ b/include/media/v4l2-fwnode.h\n> > @@ -249,4 +249,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(\n> >  \t\t\t    struct v4l2_fwnode_endpoint *vep,\n> >  \t\t\t    struct v4l2_async_subdev *asd));\n> >  \n> > +/**\n> > + * v4l2_async_notifier_parse_fwnode_endpoint - Set up async notifier for an\n> > + *\t\t\t\t\t       fwnode based sub-device\n> > + * @dev: @struct device pointer\n> > + * @notifier: pointer to &struct v4l2_async_notifier\n> > + * @port_id: port number\n> > + * @endpoint_id: endpoint number\n> > + * @asd_struct_size: size of the driver's async sub-device struct, including\n> > + *\t\t     sizeof(struct v4l2_async_subdev). The &struct\n> > + *\t\t     v4l2_async_subdev shall be the first member of\n> > + *\t\t     the driver's async sub-device struct, i.e. both\n> > + *\t\t     begin at the same memory address.\n> > + * @parse_single: driver's callback function called on each V4L2 fwnode endpoint\n> > + *\n> > + * Parse the fwnode endpoint of the @dev device corresponding to the given port\n> > + * and endpoint numbres and populate the async sub- devices array of the\n> \n> numbers\n> no space after sub-\n> \n> > + * notifier. The @parse_endpoint callback function is called for the endpoint\n> \n> parse_single, but (as in the previous patch) I actually prefer parse_endpoint.\n> \n> > + * with the corresponding async sub-device pointer to let the caller initialize\n> > + * the driver-specific part of the async sub-device structure.\n> > + *\n> > + * The notifier memory shall be zeroed before this function is called on the\n> > + * notifier.\n> \n> Should it? Doesn't this add additional subdevs?\n> \n> I'm lost. What's the relationship between v4l2_async_notifier_parse_fwnode_endpoints\n> and this function? When do you use which? When you should zero the notifier?\n\nI thought there would be advantages in this approach as it lets you to\nchoose which endpoints specifically you want to parse. That said, the\nexpectation is that the device has no endpoints that aren't supported in\nhardware either.\n\nSome drivers currently iterate over all the endpoints and then validate\nthem whereas others poke for some endpoints only (port 0, endpoint 0, for\nthe rcar-vin driver, for instance). In DT binding documentation the\nendpoint numbers are currently not specified nor drivers have checked them.\nCommon sense tells to use zero if there's no reason to do otherwise, but\nstill this hasn't been documented nor validated in the past. So if we add\nthat now, there could be a chance of breaking something.\n\nAdditionally, specifying the endpoints to parse explicitly has been seen\nbeneficial (or even necessary) in parsing endpoints for devices that have\nboth input and output interfaces. Perhaps Niklas can comment on that.\n\nWhat I though was to introduce a specific error code (EPERM, better\nsuggestions are taken) for the driver callback function (parse_endpoint) to\nsilently skip endpoints the driver doesn't like for reason or another. This\nlets drivers to use the endpoint parser function added by the previous\npatch and still maintain the old behaviour, i.e. ignore endpoints that\naren't explicitly recognised by the driver.\n\nI'll drop this patch from the next version.","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkZQT42Trz9sRV\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tSat,  2 Sep 2017 08:57:53 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752603AbdIAW5w (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tFri, 1 Sep 2017 18:57:52 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:37160 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1752563AbdIAW5v (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Fri, 1 Sep 2017 18:57:51 -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 30F9F600DF;\n\tSat,  2 Sep 2017 01:57:49 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from <sakke@valkosipuli.retiisi.org.uk>)\n\tid 1dnusm-0001tK-Lo; Sat, 02 Sep 2017 01:57:48 +0300"],"Date":"Sat, 2 Sep 2017 01:57:48 +0300","From":"Sakari Ailus <sakari.ailus@iki.fi>","To":"Hans Verkuil <hverkuil@xs4all.nl>","Cc":"Sakari Ailus <sakari.ailus@linux.intel.com>,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, laurent.pinchart@ideasonboard.com,\n\tdevicetree@vger.kernel.org","Subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","Message-ID":"<20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk>","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<20170830114946.17743-6-sakari.ailus@linux.intel.com>\n\t<95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762099,"web_url":"http://patchwork.ozlabs.org/comment/1762099/","msgid":"<1981884.TcuAFemERJ@avalon>","list_archive_url":null,"date":"2017-09-02T09:52:47","subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","submitter":{"id":11034,"url":"http://patchwork.ozlabs.org/api/people/11034/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Sakari,\n\nOn Saturday, 2 September 2017 01:57:48 EEST Sakari Ailus wrote:\n> On Fri, Sep 01, 2017 at 01:28:40PM +0200, Hans Verkuil wrote:\n> >> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h\n> >> index d063ab4ff67b..dd13604178b4 100644\n> >> --- a/include/media/v4l2-fwnode.h\n> >> +++ b/include/media/v4l2-fwnode.h\n> >> @@ -249,4 +249,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(\n> >>  \t\t\t    struct v4l2_fwnode_endpoint *vep,\n> >>  \t\t\t    struct v4l2_async_subdev *asd));\n> >> \n> >> +/**\n> >> + * v4l2_async_notifier_parse_fwnode_endpoint - Set up async notifier\n> >> for an\n> >> + *\t\t\t\t\t       fwnode based sub-device\n> >> + * @dev: @struct device pointer\n> >> + * @notifier: pointer to &struct v4l2_async_notifier\n> >> + * @port_id: port number\n> >> + * @endpoint_id: endpoint number\n> >> + * @asd_struct_size: size of the driver's async sub-device struct,\n> >> including\n> >> + *\t\t     sizeof(struct v4l2_async_subdev). The &struct\n> >> + *\t\t     v4l2_async_subdev shall be the first member of\n> >> + *\t\t     the driver's async sub-device struct, i.e. both\n> >> + *\t\t     begin at the same memory address.\n> >> + * @parse_single: driver's callback function called on each V4L2 fwnode\n> >> endpoint\n> >> + *\n> >> + * Parse the fwnode endpoint of the @dev device corresponding to the\n> >> given port\n> >> + * and endpoint numbres and populate the async sub- devices array of\n> >> the\n> > \n> > numbers\n> > no space after sub-\n> > \n> > > + * notifier. The @parse_endpoint callback function is called for the\n> > > endpoint\n> > \n> > parse_single, but (as in the previous patch) I actually prefer\n> > parse_endpoint.\n> > \n> >> + * with the corresponding async sub-device pointer to let the caller\n> >> initialize\n> >> + * the driver-specific part of the async sub-device structure.\n> >> + *\n> >> + * The notifier memory shall be zeroed before this function is called\n> >> on the\n> >> + * notifier.\n> > \n> > Should it? Doesn't this add additional subdevs?\n> > \n> > I'm lost. What's the relationship between\n> > v4l2_async_notifier_parse_fwnode_endpoints and this function? When do you\n> > use which? When you should zero the notifier?\n> I thought there would be advantages in this approach as it lets you to\n> choose which endpoints specifically you want to parse. That said, the\n> expectation is that the device has no endpoints that aren't supported in\n> hardware either.\n> \n> Some drivers currently iterate over all the endpoints and then validate\n> them whereas others poke for some endpoints only (port 0, endpoint 0, for\n> the rcar-vin driver, for instance). In DT binding documentation the\n> endpoint numbers are currently not specified nor drivers have checked them.\n> Common sense tells to use zero if there's no reason to do otherwise, but\n> still this hasn't been documented nor validated in the past. So if we add\n> that now, there could be a chance of breaking something.\n> \n> Additionally, specifying the endpoints to parse explicitly has been seen\n> beneficial (or even necessary) in parsing endpoints for devices that have\n> both input and output interfaces. Perhaps Niklas can comment on that.\n> \n> What I though was to introduce a specific error code (EPERM, better\n> suggestions are taken)\n\nMaybe ENOTCONN ?\n\n> for the driver callback function (parse_endpoint) to silently skip endpoints\n> the driver doesn't like for reason or another. This lets drivers to use the\n> endpoint parser function added by the previous patch and still maintain the\n> old behaviour, i.e. ignore endpoints that aren't explicitly recognised by\n> the driver.\n> \n> I'll drop this patch from the next version.\n\nParsing a specific endpoint of a specific port is probably indeed a bit too \nfine-grained, but I think there are use cases for parsing at the port level \ninstead of parsing all ports.","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"hSRpsY/K\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xkryF0hxDz9s7g\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tSat,  2 Sep 2017 19:52:53 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751348AbdIBJwt (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tSat, 2 Sep 2017 05:52:49 -0400","from galahad.ideasonboard.com ([185.26.127.97]:47037 \"EHLO\n\tgalahad.ideasonboard.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751033AbdIBJwt (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Sat, 2 Sep 2017 05:52:49 -0400","from avalon.localnet (unknown [90.168.88.156])\n\tby galahad.ideasonboard.com (Postfix) with ESMTPSA id DEC2020218;\n\tSat,  2 Sep 2017 11:50:54 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1504345855;\n\tbh=hgvpV0HMYXQth7NpcDl3QbpOblv9f9Py/I+u0IBU4yA=;\n\th=From:To:Cc:Subject:Date:In-Reply-To:References:From;\n\tb=hSRpsY/Kgl2vP1qivcYT0Td4aYvV4Mv4E1o31KIsAiXdLHpRtkp/XW5y2lHijsO+F\n\t5ZgPo4TSm3lziEtUVNSsT+ZZs4u6JrQIdqek3Wlwvy1TGBhpN8vQWTadz6IzSnCYjC\n\th3zVHlqPzrrkHFBoQc8aP+/B2QQy6fpOx5bG6I+A=","From":"Laurent Pinchart <laurent.pinchart@ideasonboard.com>","To":"Sakari Ailus <sakari.ailus@iki.fi>","Cc":"Hans Verkuil <hverkuil@xs4all.nl>,\n\tSakari Ailus <sakari.ailus@linux.intel.com>,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","Date":"Sat, 02 Sep 2017 12:52:47 +0300","Message-ID":"<1981884.TcuAFemERJ@avalon>","In-Reply-To":"<20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk>","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>\n\t<20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762224,"web_url":"http://patchwork.ozlabs.org/comment/1762224/","msgid":"<20170903074339.vswbczv2lfxykssq@valkosipuli.retiisi.org.uk>","list_archive_url":null,"date":"2017-09-03T07:43:39","subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","submitter":{"id":1593,"url":"http://patchwork.ozlabs.org/api/people/1593/","name":"Sakari Ailus","email":"sakari.ailus@iki.fi"},"content":"Hi Laurent,\n\nOn Sat, Sep 02, 2017 at 12:52:47PM +0300, Laurent Pinchart wrote:\n> Hi Sakari,\n> \n> On Saturday, 2 September 2017 01:57:48 EEST Sakari Ailus wrote:\n> > On Fri, Sep 01, 2017 at 01:28:40PM +0200, Hans Verkuil wrote:\n> > >> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h\n> > >> index d063ab4ff67b..dd13604178b4 100644\n> > >> --- a/include/media/v4l2-fwnode.h\n> > >> +++ b/include/media/v4l2-fwnode.h\n> > >> @@ -249,4 +249,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(\n> > >>  \t\t\t    struct v4l2_fwnode_endpoint *vep,\n> > >>  \t\t\t    struct v4l2_async_subdev *asd));\n> > >> \n> > >> +/**\n> > >> + * v4l2_async_notifier_parse_fwnode_endpoint - Set up async notifier\n> > >> for an\n> > >> + *\t\t\t\t\t       fwnode based sub-device\n> > >> + * @dev: @struct device pointer\n> > >> + * @notifier: pointer to &struct v4l2_async_notifier\n> > >> + * @port_id: port number\n> > >> + * @endpoint_id: endpoint number\n> > >> + * @asd_struct_size: size of the driver's async sub-device struct,\n> > >> including\n> > >> + *\t\t     sizeof(struct v4l2_async_subdev). The &struct\n> > >> + *\t\t     v4l2_async_subdev shall be the first member of\n> > >> + *\t\t     the driver's async sub-device struct, i.e. both\n> > >> + *\t\t     begin at the same memory address.\n> > >> + * @parse_single: driver's callback function called on each V4L2 fwnode\n> > >> endpoint\n> > >> + *\n> > >> + * Parse the fwnode endpoint of the @dev device corresponding to the\n> > >> given port\n> > >> + * and endpoint numbres and populate the async sub- devices array of\n> > >> the\n> > > \n> > > numbers\n> > > no space after sub-\n> > > \n> > > > + * notifier. The @parse_endpoint callback function is called for the\n> > > > endpoint\n> > > \n> > > parse_single, but (as in the previous patch) I actually prefer\n> > > parse_endpoint.\n> > > \n> > >> + * with the corresponding async sub-device pointer to let the caller\n> > >> initialize\n> > >> + * the driver-specific part of the async sub-device structure.\n> > >> + *\n> > >> + * The notifier memory shall be zeroed before this function is called\n> > >> on the\n> > >> + * notifier.\n> > > \n> > > Should it? Doesn't this add additional subdevs?\n> > > \n> > > I'm lost. What's the relationship between\n> > > v4l2_async_notifier_parse_fwnode_endpoints and this function? When do you\n> > > use which? When you should zero the notifier?\n> > I thought there would be advantages in this approach as it lets you to\n> > choose which endpoints specifically you want to parse. That said, the\n> > expectation is that the device has no endpoints that aren't supported in\n> > hardware either.\n> > \n> > Some drivers currently iterate over all the endpoints and then validate\n> > them whereas others poke for some endpoints only (port 0, endpoint 0, for\n> > the rcar-vin driver, for instance). In DT binding documentation the\n> > endpoint numbers are currently not specified nor drivers have checked them.\n> > Common sense tells to use zero if there's no reason to do otherwise, but\n> > still this hasn't been documented nor validated in the past. So if we add\n> > that now, there could be a chance of breaking something.\n> > \n> > Additionally, specifying the endpoints to parse explicitly has been seen\n> > beneficial (or even necessary) in parsing endpoints for devices that have\n> > both input and output interfaces. Perhaps Niklas can comment on that.\n> > \n> > What I though was to introduce a specific error code (EPERM, better\n> > suggestions are taken)\n> \n> Maybe ENOTCONN ?\n\nSounds good to me.\n\n> \n> > for the driver callback function (parse_endpoint) to silently skip endpoints\n> > the driver doesn't like for reason or another. This lets drivers to use the\n> > endpoint parser function added by the previous patch and still maintain the\n> > old behaviour, i.e. ignore endpoints that aren't explicitly recognised by\n> > the driver.\n> > \n> > I'll drop this patch from the next version.\n> \n> Parsing a specific endpoint of a specific port is probably indeed a bit too \n> fine-grained, but I think there are use cases for parsing at the port level \n> instead of parsing all ports.\n\nCould you elaborate?\n\nIf a driver would be interested in skipping endpoints in a subset of ports,\nin which case only a single port would be excluded from this?","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xlQ2n1H3Gz9s83\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tSun,  3 Sep 2017 17:43:45 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751129AbdICHnn (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tSun, 3 Sep 2017 03:43:43 -0400","from nblzone-211-213.nblnetworks.fi ([83.145.211.213]:46250 \"EHLO\n\thillosipuli.retiisi.org.uk\" rhost-flags-OK-OK-OK-FAIL)\n\tby vger.kernel.org with ESMTP id S1751030AbdICHnm (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Sun, 3 Sep 2017 03:43:42 -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 82184600E5;\n\tSun,  3 Sep 2017 10:43:40 +0300 (EEST)","from sakke by valkosipuli.localdomain with local (Exim 4.89)\n\t(envelope-from <sakke@valkosipuli.retiisi.org.uk>)\n\tid 1doPZD-00026c-PY; Sun, 03 Sep 2017 10:43:39 +0300"],"Date":"Sun, 3 Sep 2017 10:43:39 +0300","From":"Sakari Ailus <sakari.ailus@iki.fi>","To":"Laurent Pinchart <laurent.pinchart@ideasonboard.com>","Cc":"Hans Verkuil <hverkuil@xs4all.nl>,\n\tSakari Ailus <sakari.ailus@linux.intel.com>,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","Message-ID":"<20170903074339.vswbczv2lfxykssq@valkosipuli.retiisi.org.uk>","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>\n\t<20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk>\n\t<1981884.TcuAFemERJ@avalon>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1981884.TcuAFemERJ@avalon>","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1762550,"web_url":"http://patchwork.ozlabs.org/comment/1762550/","msgid":"<41798047.7Eux7kmorh@avalon>","list_archive_url":null,"date":"2017-09-04T10:05:52","subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","submitter":{"id":11034,"url":"http://patchwork.ozlabs.org/api/people/11034/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Sakari,\n\nOn Sunday, 3 September 2017 10:43:39 EEST Sakari Ailus wrote:\n> On Sat, Sep 02, 2017 at 12:52:47PM +0300, Laurent Pinchart wrote:\n> > On Saturday, 2 September 2017 01:57:48 EEST Sakari Ailus wrote:\n> >> On Fri, Sep 01, 2017 at 01:28:40PM +0200, Hans Verkuil wrote:\n\n[sinp]\n\n> >>> I'm lost. What's the relationship between\n> >>> v4l2_async_notifier_parse_fwnode_endpoints and this function? When do\n> >>> you use which? When you should zero the notifier?\n> >> \n> >> I thought there would be advantages in this approach as it lets you to\n> >> choose which endpoints specifically you want to parse. That said, the\n> >> expectation is that the device has no endpoints that aren't supported in\n> >> hardware either.\n> >> \n> >> Some drivers currently iterate over all the endpoints and then validate\n> >> them whereas others poke for some endpoints only (port 0, endpoint 0,\n> >> for the rcar-vin driver, for instance). In DT binding documentation the\n> >> endpoint numbers are currently not specified nor drivers have checked\n> >> them. Common sense tells to use zero if there's no reason to do\n> >> otherwise, but still this hasn't been documented nor validated in the\n> >> past. So if we add that now, there could be a chance of breaking\n> >> something.\n> >> \n> >> Additionally, specifying the endpoints to parse explicitly has been seen\n> >> beneficial (or even necessary) in parsing endpoints for devices that\n> >> have both input and output interfaces. Perhaps Niklas can comment on\n> >> that.\n> >> \n> >> What I though was to introduce a specific error code (EPERM, better\n> >> suggestions are taken)\n> > \n> > Maybe ENOTCONN ?\n> \n> Sounds good to me.\n> \n> >> for the driver callback function (parse_endpoint) to silently skip\n> >> endpoints the driver doesn't like for reason or another. This lets\n> >> drivers to use the endpoint parser function added by the previous patch\n> >> and still maintain the old behaviour, i.e. ignore endpoints that aren't\n> >> explicitly recognised by the driver.\n> >> \n> >> I'll drop this patch from the next version.\n> > \n> > Parsing a specific endpoint of a specific port is probably indeed a bit\n> > too fine-grained, but I think there are use cases for parsing at the port\n> > level instead of parsing all ports.\n> \n> Could you elaborate?\n> \n> If a driver would be interested in skipping endpoints in a subset of ports,\n> in which case only a single port would be excluded from this?\n\nI meant that I see use cases for parsing specific ports only (for instance in \nthe R-Car case parsing only the sink ports in a CSI-2 receiver DT node), but \nnot really for parsing specific endpoints only.","headers":{"Return-Path":"<devicetree-owner@vger.kernel.org>","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=<UNKNOWN>)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"gh25oZVY\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xm58N3fd7z9s7f\n\tfor <incoming-dt@patchwork.ozlabs.org>;\n\tMon,  4 Sep 2017 20:05:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753449AbdIDKFy (ORCPT\n\t<rfc822;incoming-dt@patchwork.ozlabs.org>);\n\tMon, 4 Sep 2017 06:05:54 -0400","from galahad.ideasonboard.com ([185.26.127.97]:60385 \"EHLO\n\tgalahad.ideasonboard.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753422AbdIDKFy (ORCPT\n\t<rfc822; devicetree@vger.kernel.org>); Mon, 4 Sep 2017 06:05:54 -0400","from avalon.localnet (unknown [90.168.88.156])\n\tby galahad.ideasonboard.com (Postfix) with ESMTPSA id 30D4F20218;\n\tMon,  4 Sep 2017 12:03:55 +0200 (CEST)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1504519435;\n\tbh=RCxJCLan9y3US2JKZq99f7SU1LqQwmnIkE7E6DLzmX4=;\n\th=From:To:Cc:Subject:Date:In-Reply-To:References:From;\n\tb=gh25oZVYpYLlVoVi7jNWypWVWgjLO2xO3q1dsH/UmWYCeoyRF5XbQkdrnof/3A843\n\t96Nn2v5eY4g7vVQnUTyMvPFrdVQpgPlg5K17bMFPiPeLs/75Hx2AbSigkrPSTy7+CL\n\tHs3Y2oCY3hRuMhd5GCdO18HwFOu1Jtcnt+v8Jcv8=","From":"Laurent Pinchart <laurent.pinchart@ideasonboard.com>","To":"Sakari Ailus <sakari.ailus@iki.fi>","Cc":"Hans Verkuil <hverkuil@xs4all.nl>,\n\tSakari Ailus <sakari.ailus@linux.intel.com>,\n\tlinux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,\n\trobh@kernel.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph\n\tendpoints in a single port","Date":"Mon, 04 Sep 2017 13:05:52 +0300","Message-ID":"<41798047.7Eux7kmorh@avalon>","In-Reply-To":"<20170903074339.vswbczv2lfxykssq@valkosipuli.retiisi.org.uk>","References":"<20170830114946.17743-1-sakari.ailus@linux.intel.com>\n\t<1981884.TcuAFemERJ@avalon>\n\t<20170903074339.vswbczv2lfxykssq@valkosipuli.retiisi.org.uk>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"<devicetree.vger.kernel.org>","X-Mailing-List":"devicetree@vger.kernel.org"}}]