[{"id":1773646,"web_url":"http://patchwork.ozlabs.org/comment/1773646/","msgid":"<20170922142758.GE3475@red-moon>","list_archive_url":null,"date":"2017-09-22T14:27:58","subject":"Re: [PATCH v7 3/5] iommu/of: Add msi address regions reservation\n\thelper","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"John, Shameer,\n\nOn Thu, Sep 14, 2017 at 01:57:54PM +0100, Shameer Kolothum wrote:\n> From: John Garry \n> \n> On some platforms msi-controller address regions have to be excluded\n> from normal IOVA allocation in that they are detected and decoded in\n> a HW specific way by system components and so they cannot be considered\n> normal IOVA address space.\n> \n> Add a helper function that retrieves msi address regions through device\n> tree msi mapping, so that these regions will not be translated by IOMMU\n> and will be excluded from IOVA allocations.\n> \n> Signed-off-by: John Garry \n> Signed-off-by: Shameer Kolothum \n> ---\n> drivers/iommu/of_iommu.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++\n> include/linux/of_iommu.h | 10 ++++\n> 2 files changed, 127 insertions(+)\n> \n> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c\n> index 8cb6082..f2d1a76 100644\n> --- a/drivers/iommu/of_iommu.c\n> +++ b/drivers/iommu/of_iommu.c\n> @@ -21,6 +21,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -246,6 +247,122 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,\n> \treturn ops;\n> }\n> \n> +/**\n> + * of_iommu_msi_get_resv_regions - Reserved region driver helper\n> + * @dev: Device from iommu_get_resv_regions()\n> + * @list: Reserved region list from iommu_get_resv_regions()\n> + *\n> + * Returns: Number of reserved regions on success (0 if no associated\n> + * msi parent), appropriate error value otherwise.\n> + */\n> +int of_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)\n> +{\n> +\tint prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;\n> +\tstruct iommu_resv_region *region;\n> +\tstruct device_node *np;\n> +\tstruct resource res;\n> +\tint i, resv = 0, mappings = 0;\n> +\n> +\tif (dev_is_pci(dev)) {\n> +\t\tstruct device *dma_dev, *bridge;\n> +\t\tstruct of_phandle_args iommu_spec;\n> +\t\tstruct pci_dev *pdev = to_pci_dev(dev);\n> +\t\tint err, count;\n> +\t\tu32 rid, map_mask;\n> +\t\tconst __be32 *msi_map;\n> +\n> +\t\tbridge = pci_get_host_bridge_device(pdev);\n> +\t\tdma_dev = bridge->parent;\n> +\t\tpci_put_host_bridge_device(bridge);\n> +\n> +\t\tif (!dma_dev->of_node)\n> +\t\t\treturn -ENODEV;\n> +\n> +\t\tiommu_spec.args_count = 1;\n> +\t\tnp = iommu_spec.np = dma_dev->of_node;\n> +\t\tpci_for_each_dma_alias(pdev, __get_pci_rid, &iommu_spec);\n> +\n> +\t\trid = iommu_spec.args[0];\n> +\t\tif (!of_property_read_u32(np, \"msi-map-mask\", &map_mask))\n> +\t\t\trid &= map_mask;\n> +\n> +\t\tmsi_map = of_get_property(np, \"msi-map\", NULL);\n> +\t\tif (!msi_map)\n> +\t\t\treturn -ENODEV;\n> +\n> +\t\tmappings = of_count_phandle_with_args(np, \"msi-map\", NULL) / 4;\n> +\n> +\t\tfor (i = 0, count = mappings; i < count; i++, msi_map += 4) {\n> +\t\t\tstruct device_node *msi_node;\n> +\t\t\tu32 rid_base, rid_len, phandle;\n> +\n> +\t\t\trid_base = be32_to_cpup(msi_map + 0);\n> +\t\t\tphandle = be32_to_cpup(msi_map + 1);\n> +\t\t\trid_len = be32_to_cpup(msi_map + 3);\n> +\n> +\t\t\t/* check rid is within range */\n> +\t\t\tif (rid < rid_base || rid >= rid_base + rid_len) {\n> +\t\t\t\tmappings--;\n> +\t\t\t\tcontinue;\n> +\t\t\t}\n> +\n> +\t\t\tmsi_node = of_find_node_by_phandle(phandle);\n> +\t\t\tif (!msi_node)\n> +\t\t\t\treturn -ENODEV;\n\nThis is basically of_pci_map_rid(), I wonder whether there is not\na way to consolidate some code here - duplicating certainly does not\nhelp. To make MSI reservations generic this is probably the only way\nto do it but it would be nice to reuse some OF MSI code.\n\nWith the current kernel API there is a way but it is a bit whacky.\n\nJust loop over \"msi-controller\" nodes and try to map the device to\nthem through of_pci_map_rid, if mapping succeeds reserve region for\nthe target node.\n\nNot a big fan of what I am proposing but it certainly helps reuse\nsome existing code that makes no sense to duplicate.\n\n> +\t\t\terr = of_address_to_resource(msi_node, 0, &res);\n> +\t\t\tof_node_put(msi_node);\n> +\t\t\tif (err)\n> +\t\t\t\treturn err;\n> +\n> +\t\t\tregion = iommu_alloc_resv_region(res.start,\n> +\t\t\t\t\t\t\t resource_size(&res),\n> +\t\t\t\t\t\t\t prot, IOMMU_RESV_MSI);\n> +\t\t\tif (region) {\n> +\t\t\t\tlist_add_tail(®ion->list, head);\n> +\t\t\t\tresv++;\n> +\t\t\t}\n> +\t\t}\n> +\t} else if (dev->of_node) {\n> +\t\tstruct device_node *msi_np;\n> +\t\tint index = 0;\n> +\t\tint tuples;\n> +\n> +\t\tnp = dev->of_node;\n> +\n> +\t\ttuples = of_count_phandle_with_args(np, \"msi-parent\", NULL);\n> +\n> +\t\twhile (index < tuples) {\n\nWould not be easier to have an of_parse_phandle_with_args() loop here ?\n\nLorenzo\n\n> +\t\t\tint msi_cells = 0;\n> +\t\t\tint err;\n> +\n> +\t\t\tmsi_np = of_parse_phandle(np, \"msi-parent\", index);\n> +\t\t\tif (!msi_np)\n> +\t\t\t\treturn -ENODEV;\n> +\n> +\t\t\tof_property_read_u32(msi_np, \"#msi-cells\", &msi_cells);\n> +\n> +\t\t\terr = of_address_to_resource(msi_np, 0, &res);\n> +\t\t\tof_node_put(msi_np);\n> +\t\t\tif (err)\n> +\t\t\t\treturn err;\n> +\n> +\t\t\tmappings++;\n> +\n> +\t\t\tregion = iommu_alloc_resv_region(res.start,\n> +\t\t\t\t\t\t\t resource_size(&res),\n> +\t\t\t\t\t\t\t prot, IOMMU_RESV_MSI);\n> +\t\t\tif (region) {\n> +\t\t\t\tlist_add_tail(®ion->list, head);\n> +\t\t\t\tresv++;\n> +\t\t\t}\n> +\t\t\tindex += 1 + msi_cells;\n> +\t\t}\n> +\t}\n> +\n> +\treturn (resv == mappings) ? resv : -ENODEV;\n> +}\n> +\n> static int __init of_iommu_init(void)\n> {\n> \tstruct device_node *np;\n> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h\n> index 13394ac..9267772 100644\n> --- a/include/linux/of_iommu.h\n> +++ b/include/linux/of_iommu.h\n> @@ -14,6 +14,9 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,\n> extern const struct iommu_ops *of_iommu_configure(struct device *dev,\n> \t\t\t\t\tstruct device_node *master_np);\n> \n> +extern int of_iommu_msi_get_resv_regions(struct device *dev,\n> +\t\t\t\t\tstruct list_head *head);\n> +\n> #else\n> \n> static inline int of_get_dma_window(struct device_node *dn, const char *prefix,\n> @@ -29,6 +32,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,\n> \treturn NULL;\n> }\n> \n> +static int of_iommu_msi_get_resv_regions(struct device *dev,\n> +\t\t\t\t\tstruct list_head *head)\n> +{\n> +\treturn -ENODEV;\n> +}\n> +\n> +\n> #endif\t/* CONFIG_OF_IOMMU */\n> \n> extern struct of_device_id __iommu_of_table;\n> -- \n> 1.9.1\n> \n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe linux-acpi\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\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 3xzG3f6435z9t49\n\tfor ;\n\tSat, 23 Sep 2017 00:25:34 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752426AbdIVOZb (ORCPT\n\t);\n\tFri, 22 Sep 2017 10:25:31 -0400","from foss.arm.com ([217.140.101.70]:58046 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752380AbdIVOZ3 (ORCPT );\n\tFri, 22 Sep 2017 10:25:29 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A797C1435;\n\tFri, 22 Sep 2017 07:25:28 -0700 (PDT)","from red-moon (red-moon.cambridge.arm.com [10.1.206.55])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t8EFD73F53D; Fri, 22 Sep 2017 07:25:25 -0700 (PDT)"],"Date":"Fri, 22 Sep 2017 15:27:58 +0100","From":"Lorenzo Pieralisi ","To":"Shameer Kolothum ","Cc":"marc.zyngier@arm.com, sudeep.holla@arm.com, will.deacon@arm.com,\n\trobin.murphy@arm.com, joro@8bytes.org, mark.rutland@arm.com,\n\thanjun.guo@linaro.org, gabriele.paoloni@huawei.com,\n\tjohn.garry@huawei.com, iommu@lists.linux-foundation.org,\n\tlinux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,\n\tdevicetree@vger.kernel.org, devel@acpica.org, linuxarm@huawei.com,\n\twangzhou1@hisilicon.com, guohanjun@huawei.com","Subject":"Re: [PATCH v7 3/5] iommu/of: Add msi address regions reservation\n\thelper","Message-ID":"<20170922142758.GE3475@red-moon>","References":"<20170914125756.14836-1-shameerali.kolothum.thodi@huawei.com>\n\t<20170914125756.14836-4-shameerali.kolothum.thodi@huawei.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170914125756.14836-4-shameerali.kolothum.thodi@huawei.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773703,"web_url":"http://patchwork.ozlabs.org/comment/1773703/","msgid":"<5FC3163CFD30C246ABAA99954A238FA8384142E1@FRAEML521-MBX.china.huawei.com>","list_archive_url":null,"date":"2017-09-22T15:37:52","subject":"RE: [PATCH v7 3/5] iommu/of: Add msi address regions reservation\n\thelper","submitter":{"id":70507,"url":"http://patchwork.ozlabs.org/api/people/70507/","name":"Shameerali Kolothum Thodi","email":"shameerali.kolothum.thodi@huawei.com"},"content":"> -----Original Message-----\n> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@arm.com]\n> Sent: Friday, September 22, 2017 3:28 PM\n> To: Shameerali Kolothum Thodi \n> Cc: marc.zyngier@arm.com; sudeep.holla@arm.com; will.deacon@arm.com;\n> robin.murphy@arm.com; joro@8bytes.org; mark.rutland@arm.com;\n> hanjun.guo@linaro.org; Gabriele Paoloni ;\n> John Garry ; iommu@lists.linux-foundation.org;\n> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;\n> devicetree@vger.kernel.org; devel@acpica.org; Linuxarm\n> ; Wangzhou (B) ;\n> Guohanjun (Hanjun Guo) \n> Subject: Re: [PATCH v7 3/5] iommu/of: Add msi address regions reservation\n> helper\n> \n> John, Shameer,\n> \n> On Thu, Sep 14, 2017 at 01:57:54PM +0100, Shameer Kolothum wrote:\n> > From: John Garry \n> >\n> > On some platforms msi-controller address regions have to be excluded\n> > from normal IOVA allocation in that they are detected and decoded in\n> > a HW specific way by system components and so they cannot be\n> considered\n> > normal IOVA address space.\n> >\n> > Add a helper function that retrieves msi address regions through device\n> > tree msi mapping, so that these regions will not be translated by IOMMU\n> > and will be excluded from IOVA allocations.\n> >\n> > Signed-off-by: John Garry \n> > Signed-off-by: Shameer Kolothum\n> \n> > ---\n> > drivers/iommu/of_iommu.c | 117\n> +++++++++++++++++++++++++++++++++++++++++++++++\n> > include/linux/of_iommu.h | 10 ++++\n> > 2 files changed, 127 insertions(+)\n> >\n> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c\n> > index 8cb6082..f2d1a76 100644\n> > --- a/drivers/iommu/of_iommu.c\n> > +++ b/drivers/iommu/of_iommu.c\n> > @@ -21,6 +21,7 @@\n> > #include \n> > #include \n> > #include \n> > +#include \n> > #include \n> > #include \n> > #include \n> > @@ -246,6 +247,122 @@ const struct iommu_ops\n> *of_iommu_configure(struct device *dev,\n> > \treturn ops;\n> > }\n> >\n> > +/**\n> > + * of_iommu_msi_get_resv_regions - Reserved region driver helper\n> > + * @dev: Device from iommu_get_resv_regions()\n> > + * @list: Reserved region list from iommu_get_resv_regions()\n> > + *\n> > + * Returns: Number of reserved regions on success (0 if no associated\n> > + * msi parent), appropriate error value otherwise.\n> > + */\n> > +int of_iommu_msi_get_resv_regions(struct device *dev, struct list_head\n> *head)\n> > +{\n> > +\tint prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;\n> > +\tstruct iommu_resv_region *region;\n> > +\tstruct device_node *np;\n> > +\tstruct resource res;\n> > +\tint i, resv = 0, mappings = 0;\n> > +\n> > +\tif (dev_is_pci(dev)) {\n> > +\t\tstruct device *dma_dev, *bridge;\n> > +\t\tstruct of_phandle_args iommu_spec;\n> > +\t\tstruct pci_dev *pdev = to_pci_dev(dev);\n> > +\t\tint err, count;\n> > +\t\tu32 rid, map_mask;\n> > +\t\tconst __be32 *msi_map;\n> > +\n> > +\t\tbridge = pci_get_host_bridge_device(pdev);\n> > +\t\tdma_dev = bridge->parent;\n> > +\t\tpci_put_host_bridge_device(bridge);\n> > +\n> > +\t\tif (!dma_dev->of_node)\n> > +\t\t\treturn -ENODEV;\n> > +\n> > +\t\tiommu_spec.args_count = 1;\n> > +\t\tnp = iommu_spec.np = dma_dev->of_node;\n> > +\t\tpci_for_each_dma_alias(pdev, __get_pci_rid,\n> &iommu_spec);\n> > +\n> > +\t\trid = iommu_spec.args[0];\n> > +\t\tif (!of_property_read_u32(np, \"msi-map-mask\",\n> &map_mask))\n> > +\t\t\trid &= map_mask;\n> > +\n> > +\t\tmsi_map = of_get_property(np, \"msi-map\", NULL);\n> > +\t\tif (!msi_map)\n> > +\t\t\treturn -ENODEV;\n> > +\n> > +\t\tmappings = of_count_phandle_with_args(np, \"msi-map\",\n> NULL) / 4;\n> > +\n> > +\t\tfor (i = 0, count = mappings; i < count; i++, msi_map += 4) {\n> > +\t\t\tstruct device_node *msi_node;\n> > +\t\t\tu32 rid_base, rid_len, phandle;\n> > +\n> > +\t\t\trid_base = be32_to_cpup(msi_map + 0);\n> > +\t\t\tphandle = be32_to_cpup(msi_map + 1);\n> > +\t\t\trid_len = be32_to_cpup(msi_map + 3);\n> > +\n> > +\t\t\t/* check rid is within range */\n> > +\t\t\tif (rid < rid_base || rid >= rid_base + rid_len) {\n> > +\t\t\t\tmappings--;\n> > +\t\t\t\tcontinue;\n> > +\t\t\t}\n> > +\n> > +\t\t\tmsi_node = of_find_node_by_phandle(phandle);\n> > +\t\t\tif (!msi_node)\n> > +\t\t\t\treturn -ENODEV;\n> \n> This is basically of_pci_map_rid(), I wonder whether there is not\n> a way to consolidate some code here - duplicating certainly does not\n> help. To make MSI reservations generic this is probably the only way\n> to do it but it would be nice to reuse some OF MSI code.\n> \n> With the current kernel API there is a way but it is a bit whacky.\n> \n> Just loop over \"msi-controller\" nodes and try to map the device to\n> them through of_pci_map_rid, if mapping succeeds reserve region for\n> the target node.\n> \n> Not a big fan of what I am proposing but it certainly helps reuse\n> some existing code that makes no sense to duplicate.\n\nRight, lot of this is of_pci_map_rid() code. And just to confirm, \nI think the proposal is to make use of the @target node param in \nof_pci_map_rid() for a matching \"msi-controller\".\n\n> > +\t\t\terr = of_address_to_resource(msi_node, 0, &res);\n> > +\t\t\tof_node_put(msi_node);\n> > +\t\t\tif (err)\n> > +\t\t\t\treturn err;\n> > +\n> > +\t\t\tregion = iommu_alloc_resv_region(res.start,\n> > +\t\t\t\t\t\t\t resource_size(&res),\n> > +\t\t\t\t\t\t\t prot,\n> IOMMU_RESV_MSI);\n> > +\t\t\tif (region) {\n> > +\t\t\t\tlist_add_tail(®ion->list, head);\n> > +\t\t\t\tresv++;\n> > +\t\t\t}\n> > +\t\t}\n> > +\t} else if (dev->of_node) {\n> > +\t\tstruct device_node *msi_np;\n> > +\t\tint index = 0;\n> > +\t\tint tuples;\n> > +\n> > +\t\tnp = dev->of_node;\n> > +\n> > +\t\ttuples = of_count_phandle_with_args(np, \"msi-parent\",\n> NULL);\n> > +\n> > +\t\twhile (index < tuples) {\n> \n> Would not be easier to have an of_parse_phandle_with_args() loop here ?\n\nOk. Many thanks for going through this. We will rework this based on your\nsuggestions and send out the next revision (rebased on -rc1).\n\nThanks,\nShameer\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 3xzHhL1Nlwz9s7h\n\tfor ;\n\tSat, 23 Sep 2017 01:38:58 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751977AbdIVPi4 convert rfc822-to-8bit (ORCPT\n\t);\n\tFri, 22 Sep 2017 11:38:56 -0400","from lhrrgout.huawei.com ([194.213.3.17]:36430 \"EHLO\n\tlhrrgout.huawei.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751876AbdIVPiz (ORCPT\n\t); Fri, 22 Sep 2017 11:38:55 -0400","from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com)\n\t([172.18.7.190])\n\tby lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)\n\twith ESMTP id DWA20718; Fri, 22 Sep 2017 15:38:10 +0000 (GMT)","from FRAEML702-CAH.china.huawei.com (10.206.14.33) by\n\tlhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP\n\tServer (TLS) id 14.3.301.0; Fri, 22 Sep 2017 16:38:03 +0100","from FRAEML521-MBX.china.huawei.com ([169.254.1.161]) by\n\tfraeml702-cah.china.huawei.com ([10.206.14.33]) with mapi id\n\t14.03.0301.000; Fri, 22 Sep 2017 17:37:53 +0200"],"From":"Shameerali Kolothum Thodi ","To":"Lorenzo Pieralisi ","CC":"\"marc.zyngier@arm.com\" ,\n\t\"sudeep.holla@arm.com\" ,\n\t\"will.deacon@arm.com\" ,\n\t\"robin.murphy@arm.com\" ,\n\t\"joro@8bytes.org\" ,\n\t\"mark.rutland@arm.com\" ,\n\t\"hanjun.guo@linaro.org\" ,\n\tGabriele Paoloni ,\n\tJohn Garry ,\n\t\"iommu@lists.linux-foundation.org\" ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t,\n\t\"linux-acpi@vger.kernel.org\" ,\n\t\"devicetree@vger.kernel.org\" ,\n\t\"devel@acpica.org\" , Linuxarm ,\n\t\"Wangzhou (B)\" ,\n\t\"Guohanjun (Hanjun Guo)\" ","Subject":"RE: [PATCH v7 3/5] iommu/of: Add msi address regions reservation\n\thelper","Thread-Topic":"[PATCH v7 3/5] iommu/of: Add msi address regions reservation\n\thelper","Thread-Index":"AQHTLVmCIBTeBhfEukWKEYWoEWcA6aLA4b8AgAAoI6A=","Date":"Fri, 22 Sep 2017 15:37:52 +0000","Message-ID":"<5FC3163CFD30C246ABAA99954A238FA8384142E1@FRAEML521-MBX.china.huawei.com>","References":"<20170914125756.14836-1-shameerali.kolothum.thodi@huawei.com>\n\t<20170914125756.14836-4-shameerali.kolothum.thodi@huawei.com>\n\t<20170922142758.GE3475@red-moon>","In-Reply-To":"<20170922142758.GE3475@red-moon>","Accept-Language":"en-GB, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.203.177.212]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020206.59C52E63.019D, ss=1, re=0.000, recu=0.000,\n\treip=0.000, \n\tcl=1, cld=1, fgs=0, ip=169.254.1.161,\n\tso=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"64483f65fff88bb94d4f3484273f1fa1","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]