[{"id":1773491,"web_url":"http://patchwork.ozlabs.org/comment/1773491/","msgid":"<20170922112209.GA3475@red-moon>","list_archive_url":null,"date":"2017-09-22T11:22:09","subject":"Re: [RFC PATCH v2 0/4] IORT SMMUv3 MSI support","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Thu, Sep 21, 2017 at 09:17:14PM +0800, Hanjun Guo wrote:\n> From: Hanjun Guo \n> \n> IORT revision C introduced SMMUv3 MSI support for control interrupts,\n> which introduced a device ID mapping index to retrieve the dev ID\n> and ITS parent, adding its support in this patch set, please refer\n> to each patch for detail commit message.\n> \n> RFC v1 -> RFC v2:\n> - Introduce a new API iort_set_device_domain() to find the MSI domain\n> for an SMMUv3 (or any other IORT table node) to reduce the complex\n> of doing that via acpi_configure_pmsi_domain().\n> \n> Hanjun Guo (3):\n> ACPICA: Add SMMUv3 device ID mapping index support\n> ACPI: IORT: lookup iort node via fwnode\n> ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings\n> \n> Lorenzo Pieralisi (1):\n> ACPI: IORT: SMMUv3 nodes MSI support\n> \n> drivers/acpi/arm64/iort.c | 157 ++++++++++++++++++++++++++++++++++++++++++++--\n> include/acpi/actbl2.h | 1 +\n> 2 files changed, 152 insertions(+), 6 deletions(-)\n\nPlease drop RFC tag from this series, comments on respective patches.\n\nLorenzo","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"AdQQWslK\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xz9xl53dSz9sP1\n\tfor ;\n\tFri, 22 Sep 2017 21:20:11 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvM08-000734-Db; Fri, 22 Sep 2017 11:20:08 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvM01-0006CM-50 for linux-arm-kernel@lists.infradead.org;\n\tFri, 22 Sep 2017 11:20:06 +0000","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 CF46C15A2;\n\tFri, 22 Sep 2017 04:19:40 -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\t558153F578; Fri, 22 Sep 2017 04:19:39 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=nnHzeAPaalQYwR3LzXxO36YZJYR3bAUKBIVFq6h2d5M=;\n\tb=AdQQWslK59knHC\n\tlr3+DF82I9DSExnl+lUNEAnNj2q8ybuWw6dPeOXJ79kBXhcvfGnsHXC6Zlj9QJm7Q3HqcqV/sKKdJ\n\t0yViyVBWRytTlPftwYLXdjIT1Up1vADKx14wWRpTPFxDBz9r8e+6Dayk+YEZgXJ/vBUSMAozFlObd\n\t0eVi3YwaJdhIHPbKpMv2h+BzvpEA8p8WloPq2MFbgHXHf3gIwGwP3sdlwFRbQXyfR2yadwAY3fLsX\n\t2eoEBda3nQ+IOCM6fG1itdYpX46SUWOFVzvHV5oCZKjWL++uONCMt13B2wjoG4Eo2tQopcTWSmy6l\n\tIEDdj2rPxfPgH1/PHNzA==;","Date":"Fri, 22 Sep 2017 12:22:09 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [RFC PATCH v2 0/4] IORT SMMUv3 MSI support","Message-ID":"<20170922112209.GA3475@red-moon>","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170922_042001_321313_73DA24A9 ","X-CRM114-Status":"GOOD ( 10.78 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Hanjun Guo ,\n\tRobin Murphy , linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1773497,"web_url":"http://patchwork.ozlabs.org/comment/1773497/","msgid":"<20170922112508.GB3475@red-moon>","list_archive_url":null,"date":"2017-09-22T11:25:08","subject":"Re: [RFC PATCH v2 1/4] ACPICA: Add SMMUv3 device ID mapping index\n\tsupport","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Thu, Sep 21, 2017 at 09:17:15PM +0800, Hanjun Guo wrote:\n> From: Hanjun Guo \n> \n> SMMUv3 device ID mapping index is used for SMMUv3\n> MSIs, update the IORT to support that.\n> \n> Signed-off-by: Hanjun Guo \n> ---\n> include/acpi/actbl2.h | 1 +\n> 1 file changed, 1 insertion(+)\n\nHave you sent the related git pull ACPICA upstream ?\n\nLorenzo\n\n> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h\n> index 686b6f8..d90277e 100644\n> --- a/include/acpi/actbl2.h\n> +++ b/include/acpi/actbl2.h\n> @@ -810,6 +810,7 @@ struct acpi_iort_smmu_v3 {\n> \tu8 pxm;\n> \tu8 reserved1;\n> \tu16 reserved2;\n> +\tu32 id_mapping_index;\n> };\n> \n> /* Values for Model field above */\n> -- \n> 1.7.12.4\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","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"UZrK/w0i\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xzB150CmMz9sNw\n\tfor ;\n\tFri, 22 Sep 2017 21:23:05 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvM2v-00085r-6X; Fri, 22 Sep 2017 11:23:01 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvM2q-00081q-Sj for linux-arm-kernel@lists.infradead.org;\n\tFri, 22 Sep 2017 11:22:58 +0000","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 AFAA015A2;\n\tFri, 22 Sep 2017 04:22:36 -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\t35CC83F578; Fri, 22 Sep 2017 04:22:35 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=bYQ87x2jgdCyMxtDh2yrOfcxg/rCDQRaMk6LrKRYGaM=;\n\tb=UZrK/w0imqqSj8\n\tHKJjVWGDeLiePMiy5SOD6wwyTmXGwl0d96EJKGzqiGmqMRDM2FBgKjCPr6ZHWLypfrBxtUBjjtYus\n\tkeiiRDtRcKhONmMc+alQOCMCe0TOl8vl078oFLW6Vj9CjAyVr93Zm1I2ucb9X9CASWSygYn3QQ+AK\n\tP8a+8wC/dknXCWmqzRnCuac/qoUunJ50TUq4UfTjqyAhTSQXtWl1+tnsi4e1UQ9lPAgaOePU/VyxJ\n\tuu2y4WdfQwYWiZiJUULmG92y185DMxLDfsLqlMBhfD2hmklTq1LDmsBcuPay6TgcVP90u7fHHZ1ya\n\txIMzyEWT/3MuRelQ9XUQ==;","Date":"Fri, 22 Sep 2017 12:25:08 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [RFC PATCH v2 1/4] ACPICA: Add SMMUv3 device ID mapping index\n\tsupport","Message-ID":"<20170922112508.GB3475@red-moon>","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-2-git-send-email-guohanjun@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1505999838-52530-2-git-send-email-guohanjun@huawei.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170922_042257_048691_7F0785DC ","X-CRM114-Status":"GOOD ( 14.47 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Hanjun Guo ,\n\tRobin Murphy , linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1773565,"web_url":"http://patchwork.ozlabs.org/comment/1773565/","msgid":"<20170922125334.GC3475@red-moon>","list_archive_url":null,"date":"2017-09-22T12:53:34","subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two\n\tsteps mappings","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Thu, Sep 21, 2017 at 09:17:17PM +0800, Hanjun Guo wrote:\n> From: Hanjun Guo \n> \n> IORT revision C introduced SMMUv3 MSI support which adding a\n> device ID mapping index in SMMUv3 sub table, to get the SMMUv3\n> device ID mapping for the output ID (dev ID for ITS) and the\n> link to which ITS.\n> \n> So if a platform supports SMMUv3 MSI for control interrupt,\n> there will be a additional single map entry under SMMU, this\n> will not introduce any difference for devices just use one\n> step map to get its output ID and parent (ITS or SMMU), such\n> as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to\n> do the special handling for two steps map case such as\n> PCI/NC--->SMMUv3--->ITS.\n> \n> Take a PCI hostbridge for example,\n> \n> |----------------------|\n> | Root Complex Node |\n> |----------------------|\n> | map entry[x] |\n> |----------------------|\n> | id value |\n> | output_reference |\n> |---|------------------|\n> |\n> | |----------------------|\n> |-->| SMMUv3 |\n> |----------------------|\n> | SMMU dev ID |\n> | mapping index 0 |\n> |----------------------|\n> | map entry[0] |\n> |----------------------|\n> | id value |\n> | output_reference-----------> ITS 1 (SMMU MSI domain)\n> |----------------------|\n> | map entry[1] |\n> |----------------------|\n> | id value |\n> | output_reference-----------> ITS 2 (PCI MSI domain)\n> |----------------------|\n> \n> When the SMMU dev ID mapping index is 0, there is entry[0]\n> to map to a ITS, we need to skip that map entry for PCI\n> or NC (named component), or we may get the wrong ITS parent.\n\nWe do skip it because it is a single mapping that it is currently\nnot allowed for SMMUv3 components, right ?\n\nOk, we barf with a printk log message if we encounter such mapping\nbut the mapping won't resolve to the SMMUv3 MSI in the current\nkernel.\n\nAnyway, I think patch 3 and patch 4 should be partially squashed,\nmore about that in patch 4 comments.\n\nLorenzo\n\n> For now we have two APIs for ID mapping, iort_node_map_id()\n> and iort_node_map_platform_id(), and iort_node_map_id() is\n> used for optional two steps mapping, so we just need to\n> skip the map entry in iort_node_map_id() for non-SMMUv3\n> devices.\n> \n> Signed-off-by: Hanjun Guo \n> ---\n> drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++-\n> 1 file changed, 42 insertions(+), 1 deletion(-)\n> \n> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n> index db71d7f..269959e 100644\n> --- a/drivers/acpi/arm64/iort.c\n> +++ b/drivers/acpi/arm64/iort.c\n> @@ -366,6 +366,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n> \treturn NULL;\n> }\n> \n> +static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n> +\t\t\t\t\t u32 *index)\n> +{\n> +\tstruct acpi_iort_smmu_v3 *smmu;\n> +\n> +\t/*\n> +\t * SMMUv3 dev ID mapping index was introdueced in revision 1\n> +\t * table, not avaible in revision 0\n> +\t */\n> +\tif (node->revision < 1)\n> +\t\treturn -EINVAL;\n> +\n> +\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n> +\t/* if any of the gsi for control interrupts is not 0, ignore the MSI */\n> +\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n> +\t || smmu->sync_gsiv)\n> +\t\treturn -EINVAL;\n> +\n> +\tif (smmu->id_mapping_index >= node->mapping_count) {\n> +\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n> +\t\t node, node->type);\n> +\t\treturn -EINVAL;\n> +\t}\n> +\n> +\t*index = smmu->id_mapping_index;\n> +\treturn 0;\n> +}\n> +\n> static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t\t\t\t\t u32 id_in, u32 *id_out,\n> \t\t\t\t\t u8 type_mask)\n> @@ -375,7 +403,9 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t/* Parse the ID mapping tree to find specified node type */\n> \twhile (node) {\n> \t\tstruct acpi_iort_id_mapping *map;\n> -\t\tint i;\n> +\t\tint i, ret = -EINVAL;\n> +\t\t/* big enough for an invalid id index in practical */\n> +\t\tu32 index = U32_MAX;\n> \n> \t\tif (IORT_TYPE_MASK(node->type) & type_mask) {\n> \t\t\tif (id_out)\n> @@ -396,8 +426,19 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t\t\tgoto fail_map;\n> \t\t}\n> \n> +\t\t/*\n> +\t\t * we need to get SMMUv3 dev ID mapping index and skip its\n> +\t\t * associated ID map for single mapping cases.\n> +\t\t */\n> +\t\tif (node->type == ACPI_IORT_NODE_SMMU_V3)\n> +\t\t\tret = iort_get_smmu_v3_id_mapping_index(node, &index);\n> +\n> \t\t/* Do the ID translation */\n> \t\tfor (i = 0; i < node->mapping_count; i++, map++) {\n> +\t\t\t/* if it's a SMMUv3 device id mapping index, skip it */\n> +\t\t\tif (!ret && i == index)\n> +\t\t\t\tcontinue;\n> +\n> \t\t\tif (!iort_id_map(map, node->type, id, &id))\n> \t\t\t\tbreak;\n> \t\t}\n> -- \n> 1.7.12.4\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","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"oER7pm6h\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xzCzF2HPjz9s9Y\n\tfor ;\n\tFri, 22 Sep 2017 22:51:37 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvNQZ-0005QD-AF; Fri, 22 Sep 2017 12:51:31 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvNQS-0005K9-L8 for linux-arm-kernel@lists.infradead.org;\n\tFri, 22 Sep 2017 12:51:28 +0000","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 7F39780D;\n\tFri, 22 Sep 2017 05:51:03 -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\t178B23F578; Fri, 22 Sep 2017 05:51:00 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=SoHJOE8XY7PUVHMWJQV+YGcZbGiz9qJFSmABXSXP0K8=;\n\tb=oER7pm6hlkqe/f\n\te7kIXyPnUa+s0kJp/6PytcUwbwj3eYXQ1e+6WOUneqGr5RjnD+m0f8stmW1fnbQHCpmrrmGk9Ft5e\n\tjai0HGl/H0ps1N6GZgsqwrf3hb0u7wqfO1fUCjEtdPuKx5rg/10bVBMsnxvQf/kDA1+qUEVbJRjsz\n\tQuXXFqGtztpLu+01CxRMLhQKygmAeRaXPT8kknhOS3fpNlUvVvoP4fHgMLQR4M4538zmuHuy99qaU\n\tKx5wKfh1TJDTFMHjWiINiNahY9qWCAguo+GHSM5a3gqWJU9vz2+9WWaDLBRTty2mm7/18JIqLm7T5\n\twVN0SpONFeqKVj+zE0Vw==;","Date":"Fri, 22 Sep 2017 13:53:34 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two\n\tsteps mappings","Message-ID":"<20170922125334.GC3475@red-moon>","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-4-git-send-email-guohanjun@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1505999838-52530-4-git-send-email-guohanjun@huawei.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170922_055124_842693_3BB2CB5C ","X-CRM114-Status":"GOOD ( 28.56 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Hanjun Guo ,\n\tRobin Murphy , linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1773576,"web_url":"http://patchwork.ozlabs.org/comment/1773576/","msgid":"<20170922130741.GD3475@red-moon>","list_archive_url":null,"date":"2017-09-22T13:07:41","subject":"Re: [RFC PATCH v2 4/4] ACPI: IORT: SMMUv3 nodes MSI support","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Thu, Sep 21, 2017 at 09:17:18PM +0800, Hanjun Guo wrote:\n> From: Lorenzo Pieralisi \n> \n> Since we make single mappings valid for SMMUv3 (and PMCG), also\n> we have a mapping index for SMMUv3 MSI, we can directly use that\n> index to get the map entry, then retrieve dev ID and ITS parent\n> to add SMMUv3 MSI support.\n> \n> Introduce a new API iort_set_device_domain() to find the MSI domain\n> for an SMMUv3 (or any other IORT table node) to reduce the complex\n> of doing that via acpi_configure_pmsi_domain(), then reuse the\n> iort_node_get_id() to get the dev id for SMMU MSI.\n> \n> Signed-off-by: Lorenzo Pieralisi \n> Signed-off-by: Hanjun Guo \n> ---\n> drivers/acpi/arm64/iort.c | 99 ++++++++++++++++++++++++++++++++++++++---------\n> 1 file changed, 81 insertions(+), 18 deletions(-)\n> \n> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n> index 269959e..bbab2ab 100644\n> --- a/drivers/acpi/arm64/iort.c\n> +++ b/drivers/acpi/arm64/iort.c\n> @@ -357,7 +357,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n> \n> \tif (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {\n> \t\tif (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||\n> -\t\t node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {\n> +\t\t node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||\n> +\t\t node->type == ACPI_IORT_NODE_SMMU_V3) {\n> \t\t\t*id_out = map->output_base;\n> \t\t\treturn parent;\n> \t\t}\n> @@ -366,8 +367,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n> \treturn NULL;\n> }\n> \n> -static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n> -\t\t\t\t\t u32 *index)\n> +static int iort_get_id_mapping_index(struct acpi_iort_node *node,\n> +\t\t\t\t u32 *index)\n> {\n> \tstruct acpi_iort_smmu_v3 *smmu;\n> \n> @@ -378,20 +379,28 @@ static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n> \tif (node->revision < 1)\n> \t\treturn -EINVAL;\n> \n> -\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n> -\t/* if any of the gsi for control interrupts is not 0, ignore the MSI */\n> -\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n> -\t || smmu->sync_gsiv)\n> -\t\treturn -EINVAL;\n> +\tswitch (node->type) {\n> +\tcase ACPI_IORT_NODE_SMMU_V3:\n> +\t\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n> +\t\t/*\n> +\t\t * if any of the gsi for control interrupts is not 0,\n> +\t\t * ignore the MSI\n> +\t\t */\n> +\t\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n> +\t\t || smmu->sync_gsiv)\n> +\t\t\treturn -EINVAL;\n> \n> -\tif (smmu->id_mapping_index >= node->mapping_count) {\n> -\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n> -\t\t node, node->type);\n> +\t\tif (smmu->id_mapping_index >= node->mapping_count) {\n> +\t\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n> +\t\t\t node, node->type);\n> +\t\t\treturn -EINVAL;\n> +\t\t}\n> +\n> +\t\t*index = smmu->id_mapping_index;\n> +\t\treturn 0;\n> +\tdefault:\n> \t\treturn -EINVAL;\n> \t}\n> -\n> -\t*index = smmu->id_mapping_index;\n> -\treturn 0;\n> }\n> \n> static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> @@ -431,7 +440,7 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t\t * associated ID map for single mapping cases.\n> \t\t */\n> \t\tif (node->type == ACPI_IORT_NODE_SMMU_V3)\n\nI wanted to use:\n\niort_get_id_mapping_index()\n\nso that the node type check is done *in* that function and you do\nnot need to check it here.\n\n> -\t\t\tret = iort_get_smmu_v3_id_mapping_index(node, &index);\n> +\t\t\tret = iort_get_id_mapping_index(node, &index);\n> \n> \t\t/* Do the ID translation */\n> \t\tfor (i = 0; i < node->mapping_count; i++, map++) {\n> @@ -555,9 +564,18 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)\n> \tif (!node)\n> \t\treturn -ENODEV;\n> \n> -\tfor (i = 0; i < node->mapping_count; i++) {\n> -\t\tif (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))\n> -\t\t\treturn 0;\n> +\tif (node->type == ACPI_IORT_NODE_SMMU_V3) {\n\nDitto.\n\n> +\t\tu32 index;\n> +\n> +\t\tif (!iort_get_id_mapping_index(node, &index)) {\n> +\t\t\tif (iort_node_get_id(node, dev_id, index))\n> +\t\t\t\treturn 0;\n> +\t\t}\n> +\t} else {\n> +\t\tfor (i = 0; i < node->mapping_count; i++) {\n> +\t\t\tif (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))\n> +\t\t\t\treturn 0;\n> +\t\t}\n> \t}\n> \n> \treturn -ENODEV;\n> @@ -620,6 +638,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)\n> \treturn irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);\n> }\n\nAll changes above can be squashed with patch 3.\n\n> +static void iort_set_device_domain(struct device *dev,\n> +\t\t\t\t struct acpi_iort_node *node)\n> +{\n> +\tstruct acpi_iort_its_group *its;\n> +\tstruct acpi_iort_node *msi_parent;\n> +\tstruct acpi_iort_id_mapping *map;\n> +\tstruct fwnode_handle *iort_fwnode;\n> +\tstruct irq_domain *domain;\n> +\tint ret, index;\n> +\n> +\tret = iort_get_id_mapping_index(node, &index);\n> +\tif (ret < 0)\n> +\t\treturn;\n> +\n> +\tmap = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,\n> +\t\t\t node->mapping_offset + index * sizeof(*map));\n> +\n> +\t/* Firmware bug! */\n> +\tif (!map->output_reference ||\n> +\t !(map->flags & ACPI_IORT_ID_SINGLE_MAPPING)) {\n> +\t\tpr_err(FW_BUG \"[node %p type %d] Invalid MSI mapping\\n\",\n> +\t\t node, node->type);\n> +\t\treturn;\n> +\t}\n> +\n> +\tmsi_parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,\n> +\t\t\t\t map->output_reference);\n> +\n> +\tif (!msi_parent || msi_parent->type != ACPI_IORT_NODE_ITS_GROUP)\n> +\t\treturn;\n> +\n> +\t/* Move to ITS specific data */\n> +\tits = (struct acpi_iort_its_group *)msi_parent->node_data;\n> +\n> +\tiort_fwnode = iort_find_domain_token(its->identifiers[0]);\n> +\tif (!iort_fwnode)\n> +\t\treturn;\n> +\n> +\tdomain = irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);\n> +\tif (domain)\n> +\t\tdev_set_msi_domain(dev, domain);\n> +}\n> +\n> /**\n> * iort_get_platform_device_domain() - Find MSI domain related to a\n> * platform device\n> @@ -1246,6 +1307,8 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)\n> \t/* Configure DMA for the page table walker */\n> \tacpi_dma_configure(&pdev->dev, attr);\n> \n> +\tiort_set_device_domain(&pdev->dev, node);\n> +\n\n..and then you introduce iort_set_device_domain() and use it in a\nseparate patch.\n\nWith these changes I think we are ready to queue the series.\n\nThanks,\nLorenzo\n\n> \tret = platform_device_add(pdev);\n> \tif (ret)\n> \t\tgoto dma_deconfigure;\n> -- \n> 1.7.12.4\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","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"G4uT+tzT\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xzDHb4879z9sP1\n\tfor ;\n\tFri, 22 Sep 2017 23:05:45 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvNeD-0003cs-VT; Fri, 22 Sep 2017 13:05:37 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvNe6-0003Tu-GD for linux-arm-kernel@lists.infradead.org;\n\tFri, 22 Sep 2017 13:05:35 +0000","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 F33DF80D;\n\tFri, 22 Sep 2017 06:05:09 -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\t553D03F578; Fri, 22 Sep 2017 06:05:08 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=xzscFK5iOYqc15oasftsUPATUTh7PLtFp+L1RcWNKXQ=;\n\tb=G4uT+tzTQgAkIA\n\tgA9U660KjSC1Dwdlj81bZ8P9cM/yvwpacPPPKQYYA+RH7w3oQx1Ld1zz5oPg6ZS2kR789LpchSGWe\n\tDvnTbYRabVAVZ9Gi2Munwz7mjzQaNX1ggk6o2A8N1qFkxoOjidcoXhehorOXO1Z50T75liDHIsoxl\n\tGNyNLzZfpMJwnqn8yFLS+WoFkGs7QK5JPGpbnD+JvSo2DwCoW/qchzPlmBZOCJJeWCySHp2i1D8vi\n\t+ns1qrST3ZgWF9Q9DVLrugW/F1oyB4EqxLLJA01F3SmogSR5AsdD7w2ffJl8Y5JzUBUkeSOVwyWpd\n\tBJ5fx0vrIPJ2AQKJKDdw==;","Date":"Fri, 22 Sep 2017 14:07:41 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [RFC PATCH v2 4/4] ACPI: IORT: SMMUv3 nodes MSI support","Message-ID":"<20170922130741.GD3475@red-moon>","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-5-git-send-email-guohanjun@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1505999838-52530-5-git-send-email-guohanjun@huawei.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170922_060530_574579_E6D7A190 ","X-CRM114-Status":"GOOD ( 26.76 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Hanjun Guo ,\n\tRobin Murphy , linux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1773589,"web_url":"http://patchwork.ozlabs.org/comment/1773589/","msgid":"","list_archive_url":null,"date":"2017-09-22T13:21:57","subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two\n\tsteps mappings","submitter":{"id":65641,"url":"http://patchwork.ozlabs.org/api/people/65641/","name":"Robin Murphy","email":"robin.murphy@arm.com"},"content":"On 21/09/17 14:17, Hanjun Guo wrote:\n> From: Hanjun Guo \n> \n> IORT revision C introduced SMMUv3 MSI support which adding a\n> device ID mapping index in SMMUv3 sub table, to get the SMMUv3\n> device ID mapping for the output ID (dev ID for ITS) and the\n> link to which ITS.\n> \n> So if a platform supports SMMUv3 MSI for control interrupt,\n> there will be a additional single map entry under SMMU, this\n> will not introduce any difference for devices just use one\n> step map to get its output ID and parent (ITS or SMMU), such\n> as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to\n> do the special handling for two steps map case such as\n> PCI/NC--->SMMUv3--->ITS.\n> \n> Take a PCI hostbridge for example,\n> \n> |----------------------|\n> | Root Complex Node |\n> |----------------------|\n> | map entry[x] |\n> |----------------------|\n> | id value |\n> | output_reference |\n> |---|------------------|\n> |\n> | |----------------------|\n> |-->| SMMUv3 |\n> |----------------------|\n> | SMMU dev ID |\n> | mapping index 0 |\n> |----------------------|\n> | map entry[0] |\n> |----------------------|\n> | id value |\n> | output_reference-----------> ITS 1 (SMMU MSI domain)\n> |----------------------|\n> | map entry[1] |\n> |----------------------|\n> | id value |\n> | output_reference-----------> ITS 2 (PCI MSI domain)\n> |----------------------|\n> \n> When the SMMU dev ID mapping index is 0, there is entry[0]\n> to map to a ITS, we need to skip that map entry for PCI\n> or NC (named component), or we may get the wrong ITS parent.\n> \n> For now we have two APIs for ID mapping, iort_node_map_id()\n> and iort_node_map_platform_id(), and iort_node_map_id() is\n> used for optional two steps mapping, so we just need to\n> skip the map entry in iort_node_map_id() for non-SMMUv3\n> devices.\n> \n> Signed-off-by: Hanjun Guo \n> ---\n> drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++-\n> 1 file changed, 42 insertions(+), 1 deletion(-)\n> \n> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n> index db71d7f..269959e 100644\n> --- a/drivers/acpi/arm64/iort.c\n> +++ b/drivers/acpi/arm64/iort.c\n> @@ -366,6 +366,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n> \treturn NULL;\n> }\n> \n> +static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n> +\t\t\t\t\t u32 *index)\n> +{\n> +\tstruct acpi_iort_smmu_v3 *smmu;\n> +\n> +\t/*\n> +\t * SMMUv3 dev ID mapping index was introdueced in revision 1\n> +\t * table, not avaible in revision 0\n> +\t */\n> +\tif (node->revision < 1)\n> +\t\treturn -EINVAL;\n> +\n> +\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n> +\t/* if any of the gsi for control interrupts is not 0, ignore the MSI */\n> +\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n> +\t || smmu->sync_gsiv)\n\nTo repeat my previous comments, the ID mapping index is only ignored if\n*all* interrupts are GSIV-based.\n\nIt would be quite reasonable for gerr to be wired while everything else\nuses MSIs, especially since that's effectively the only reliable way to\nget MSI aborts reported if things are completely hosed.\n\n> +\t\treturn -EINVAL;\n> +\n> +\tif (smmu->id_mapping_index >= node->mapping_count) {\n> +\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n> +\t\t node, node->type);\n> +\t\treturn -EINVAL;\n> +\t}\n> +\n> +\t*index = smmu->id_mapping_index;\n> +\treturn 0;\n> +}\n> +\n> static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t\t\t\t\t u32 id_in, u32 *id_out,\n> \t\t\t\t\t u8 type_mask)\n> @@ -375,7 +403,9 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t/* Parse the ID mapping tree to find specified node type */\n> \twhile (node) {\n> \t\tstruct acpi_iort_id_mapping *map;\n> -\t\tint i;\n> +\t\tint i, ret = -EINVAL;\n> +\t\t/* big enough for an invalid id index in practical */\n> +\t\tu32 index = U32_MAX;\n\nAnd again, more of a style nit, but indices must be sufficiently small\nto fit into the positive half of an int, so *_id_mapping_index() really\ndoesn't need this complication of passing a separate output argument.\n\nRobin.\n\n> \t\tif (IORT_TYPE_MASK(node->type) & type_mask) {\n> \t\t\tif (id_out)\n> @@ -396,8 +426,19 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n> \t\t\tgoto fail_map;\n> \t\t}\n> \n> +\t\t/*\n> +\t\t * we need to get SMMUv3 dev ID mapping index and skip its\n> +\t\t * associated ID map for single mapping cases.\n> +\t\t */\n> +\t\tif (node->type == ACPI_IORT_NODE_SMMU_V3)\n> +\t\t\tret = iort_get_smmu_v3_id_mapping_index(node, &index);\n> +\n> \t\t/* Do the ID translation */\n> \t\tfor (i = 0; i < node->mapping_count; i++, map++) {\n> +\t\t\t/* if it's a SMMUv3 device id mapping index, skip it */\n> +\t\t\tif (!ret && i == index)\n> +\t\t\t\tcontinue;\n> +\n> \t\t\tif (!iort_id_map(map, node->type, id, &id))\n> \t\t\t\tbreak;\n> \t\t}\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"ueCPStxe\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xzDfv0JXtz9sP1\n\tfor ;\n\tFri, 22 Sep 2017 23:22:31 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvNuS-0002qr-Sg; Fri, 22 Sep 2017 13:22:24 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dvNuO-0002oZ-GO for linux-arm-kernel@lists.infradead.org;\n\tFri, 22 Sep 2017 13:22:22 +0000","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 E65ED80D;\n\tFri, 22 Sep 2017 06:21:59 -0700 (PDT)","from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t89A7F3F578; Fri, 22 Sep 2017 06:21:58 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=eNFhMBMIGoTJ9Kf7oUym/7AfiBNKvACL/h+j6wUh90Q=;\n\tb=ueCPStxeb+gRgq\n\texXQyLCo0ZuxV1cmCYKRakgIAB2HoSnrWIAjM3kOQE8w+NaThYcLUzRl8mrIC+6Wfh09lmsPsj8aO\n\tXOHwhlhv2Cp9DIlxcURDvS6ZrNGX6OjcgXUvev/oo+zrdvXqxJlBYVUew4vjH/MvAzgtPmOO6c/Wg\n\t28sBsW6erG1IqGkR57X3qHV+CzZilTLy6sZVHT4R1Qt24UAof+p2bwlLRF5gyeXTBpa/A6+eFlUL3\n\t1XuAWoIURubMZHAOc8BPkDAgHqU3ozPTwuEWgJC1UBF5/Xktm1rRcHF4mJwCXjEB6hAv+G6t8euP8\n\terRXFmSA/gJHC2T6oZPQ==;","Subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two\n\tsteps mappings","To":"Hanjun Guo ,\n\tLorenzo Pieralisi ","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-4-git-send-email-guohanjun@huawei.com>","From":"Robin Murphy ","Message-ID":"","Date":"Fri, 22 Sep 2017 14:21:57 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<1505999838-52530-4-git-send-email-guohanjun@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170922_062220_567950_AED32499 ","X-CRM114-Status":"GOOD ( 24.47 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Hanjun Guo ,\n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1775784,"web_url":"http://patchwork.ozlabs.org/comment/1775784/","msgid":"<59CAA4AB.3010309@linaro.org>","list_archive_url":null,"date":"2017-09-26T19:04:11","subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for\n\ttwo steps mappings","submitter":{"id":47236,"url":"http://patchwork.ozlabs.org/api/people/47236/","name":"Hanjun Guo","email":"hanjun.guo@linaro.org"},"content":"Hi Robin,\n\nSorry for the late reply, in Linaro Connect now..\n\nOn 09/22/2017 09:21 PM, Robin Murphy wrote:\n> On 21/09/17 14:17, Hanjun Guo wrote:\n>> From: Hanjun Guo \n>>\n>> IORT revision C introduced SMMUv3 MSI support which adding a\n>> device ID mapping index in SMMUv3 sub table, to get the SMMUv3\n>> device ID mapping for the output ID (dev ID for ITS) and the\n>> link to which ITS.\n>>\n>> So if a platform supports SMMUv3 MSI for control interrupt,\n>> there will be a additional single map entry under SMMU, this\n>> will not introduce any difference for devices just use one\n>> step map to get its output ID and parent (ITS or SMMU), such\n>> as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to\n>> do the special handling for two steps map case such as\n>> PCI/NC--->SMMUv3--->ITS.\n>>\n>> Take a PCI hostbridge for example,\n>>\n>> |----------------------|\n>> | Root Complex Node |\n>> |----------------------|\n>> | map entry[x] |\n>> |----------------------|\n>> | id value |\n>> | output_reference |\n>> |---|------------------|\n>> |\n>> | |----------------------|\n>> |-->| SMMUv3 |\n>> |----------------------|\n>> | SMMU dev ID |\n>> | mapping index 0 |\n>> |----------------------|\n>> | map entry[0] |\n>> |----------------------|\n>> | id value |\n>> | output_reference-----------> ITS 1 (SMMU MSI domain)\n>> |----------------------|\n>> | map entry[1] |\n>> |----------------------|\n>> | id value |\n>> | output_reference-----------> ITS 2 (PCI MSI domain)\n>> |----------------------|\n>>\n>> When the SMMU dev ID mapping index is 0, there is entry[0]\n>> to map to a ITS, we need to skip that map entry for PCI\n>> or NC (named component), or we may get the wrong ITS parent.\n>>\n>> For now we have two APIs for ID mapping, iort_node_map_id()\n>> and iort_node_map_platform_id(), and iort_node_map_id() is\n>> used for optional two steps mapping, so we just need to\n>> skip the map entry in iort_node_map_id() for non-SMMUv3\n>> devices.\n>>\n>> Signed-off-by: Hanjun Guo \n>> ---\n>> drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++-\n>> 1 file changed, 42 insertions(+), 1 deletion(-)\n>>\n>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n>> index db71d7f..269959e 100644\n>> --- a/drivers/acpi/arm64/iort.c\n>> +++ b/drivers/acpi/arm64/iort.c\n>> @@ -366,6 +366,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n>> \treturn NULL;\n>> }\n>>\n>> +static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n>> +\t\t\t\t\t u32 *index)\n>> +{\n>> +\tstruct acpi_iort_smmu_v3 *smmu;\n>> +\n>> +\t/*\n>> +\t * SMMUv3 dev ID mapping index was introdueced in revision 1\n>> +\t * table, not avaible in revision 0\n>> +\t */\n>> +\tif (node->revision < 1)\n>> +\t\treturn -EINVAL;\n>> +\n>> +\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n>> +\t/* if any of the gsi for control interrupts is not 0, ignore the MSI */\n>> +\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n>> +\t || smmu->sync_gsiv)\n>\n> To repeat my previous comments, the ID mapping index is only ignored if\n> *all* interrupts are GSIV-based.\n>\n> It would be quite reasonable for gerr to be wired while everything else\n> uses MSIs, especially since that's effectively the only reliable way to\n> get MSI aborts reported if things are completely hosed.\n\nOK, I missed this point, so I will modify the code as below\n\nif (smmu->event_gsiv && smmu->pri_gsiv && smmu->gerr_gsiv\n && smmu->sync_gsiv)\n\treturn -EINVAL;\n\nAm I doing this right with above code?\n\n>\n>> +\t\treturn -EINVAL;\n>> +\n>> +\tif (smmu->id_mapping_index >= node->mapping_count) {\n>> +\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n>> +\t\t node, node->type);\n>> +\t\treturn -EINVAL;\n>> +\t}\n>> +\n>> +\t*index = smmu->id_mapping_index;\n>> +\treturn 0;\n>> +}\n>> +\n>> static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n>> \t\t\t\t\t u32 id_in, u32 *id_out,\n>> \t\t\t\t\t u8 type_mask)\n>> @@ -375,7 +403,9 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n>> \t/* Parse the ID mapping tree to find specified node type */\n>> \twhile (node) {\n>> \t\tstruct acpi_iort_id_mapping *map;\n>> -\t\tint i;\n>> +\t\tint i, ret = -EINVAL;\n>> +\t\t/* big enough for an invalid id index in practical */\n>> +\t\tu32 index = U32_MAX;\n>\n> And again, more of a style nit, but indices must be sufficiently small\n> to fit into the positive half of an int, so *_id_mapping_index() really\n> doesn't need this complication of passing a separate output argument.\n\nSorry, I reused the code which Lorenzo sent me, will update the code\nin next version.\n\nThanks\nHanjun","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"SmOT6TWW\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"PZe4w5Um\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1r3x2bZdz9t2Q\n\tfor ;\n\tWed, 27 Sep 2017 05:04:45 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwv9r-0001Bh-Sh; Tue, 26 Sep 2017 19:04:39 +0000","from mail-pf0-x22d.google.com ([2607:f8b0:400e:c00::22d])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwv9n-0000qw-LS for linux-arm-kernel@lists.infradead.org;\n\tTue, 26 Sep 2017 19:04:38 +0000","by mail-pf0-x22d.google.com with SMTP id u12so5997311pfl.4\n\tfor ;\n\tTue, 26 Sep 2017 12:04:13 -0700 (PDT)","from [172.20.3.46] ([70.35.39.2])\n\tby smtp.googlemail.com with ESMTPSA id\n\tt17sm19429825pfi.31.2017.09.26.12.04.12\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 26 Sep 2017 12:04:12 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:References:Subject:To:MIME-Version:From:\n\tDate:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=uumeSSlRirZ9Lde8CGNJ2QrUEZ0G7ULdBOqgo55SXx8=;\n\tb=SmOT6TWWVKErOy6imZQv9hHMQ\n\tTXIu/yl6ZxmmTOuiA0mRD7+kTJUMN6hq+ksrNXyFuzFF1mjY9xDYKCC/hiDS3Pjhdbvm70o4XQ/zG\n\tghUo57W1M+sE4YNl8xQZdfdTPmQ5n9SSYPud1H1OJkqNpYyweqOh/2RuOZz+zFyAFrcR82PcnH7Xh\n\tTrS20rS4dKNmECXPQ9/6ieztuvQF1sjkQ4eg7j3y6gpW8LHA7604EkxIY7doPLRSNUuWEl6Odna3R\n\t3o/o3wvX/SlGSrkmZBcnrIyudZTGKTG4X9WPfzzBxwpIqzRGQiO+qzMbccFb4lqZaSby3K9n1wBif\n\t2qWUwBxEw==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=message-id:date:from:user-agent:mime-version:to:cc:subject\n\t:references:in-reply-to:content-transfer-encoding;\n\tbh=UlsigecRMfVBdYf6RFk7uvX/kObdU3FkMzDjxgO0OL0=;\n\tb=PZe4w5UmZgV4Fjn1KOlw1DvV/liUsksRJsVCp/Rmo7lP6LqkyhutRUGwKFwgdclW0K\n\twm6qc7Ok7nKV7cVrjVe7ItE5ILXvDWrKOsDDcSK8myhg86okFHErsYqN6glPb4NKuXI7\n\t3Sdfc+tWUpEKsaJx/BQ/Rve0DtYosFa+DGCyc="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:date:from:user-agent:mime-version:to\n\t:cc:subject:references:in-reply-to:content-transfer-encoding;\n\tbh=UlsigecRMfVBdYf6RFk7uvX/kObdU3FkMzDjxgO0OL0=;\n\tb=k89RzCaRp+sNhVYyVmF3q54azl2O1LRgij4Gb1ahaiPPBe22ad4cdBZrj8fVHaDGtw\n\tPly0sStgx786lc+t/lFJ9RlU5ftr/yRQ3IrvaAUmkPJcFPqd0uj0JosT03eIyFM7ZCN6\n\tVZsCY4VCZhHjQfmCCsXcANBWuBj6mB3IK/UHub4jmDkTv6BR551afqJvaH11gOcPx9Yr\n\tCTLRo8c19R+LIMB18tSUhTC6E0rTcd7n9VEn7Kc5LDeKHN9gjJ9u6idklaYzC8lXDYGK\n\tlzpe+r61MG6TjU7aF8QxAq13PZLRpojmfYkdyiyUiBNrvNkTW6C7Yio/l0icPHvMc9C6\n\tnzDg==","X-Gm-Message-State":"AHPjjUjPHyxSVLCxCFtKkU8H3OR+utGO5R4E6VHq2n4lriGecit9hi4M\n\tflXnJ+76M3ivzURs0rq5/bFZHTTbGj0=","X-Google-Smtp-Source":"AOwi7QBV7P2+NQAoW+D2p/w+ZdxXmdvfRT2iN2auuIUh/IT0+p9hK4lXIs5VDJSr4vOjjLo1qwYLYA==","X-Received":"by 10.98.86.73 with SMTP id k70mr11493036pfb.345.1506452653424; \n\tTue, 26 Sep 2017 12:04:13 -0700 (PDT)","Message-ID":"<59CAA4AB.3010309@linaro.org>","Date":"Wed, 27 Sep 2017 03:04:11 +0800","From":"Hanjun Guo ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Thunderbird/31.7.0","MIME-Version":"1.0","To":"Robin Murphy , Hanjun Guo , \n\tLorenzo Pieralisi ","Subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for\n\ttwo steps mappings","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-4-git-send-email-guohanjun@huawei.com>\n\t","In-Reply-To":"","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170926_120435_748034_E092AAFB ","X-CRM114-Status":"GOOD ( 25.20 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c00:0:0:0:22d listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Marc Zyngier , linux-acpi@vger.kernel.org,\n\tlinuxarm@huawei.com, linux-arm-kernel@lists.infradead.org,\n\t\"Rafael J. Wysocki\" ","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1775881,"web_url":"http://patchwork.ozlabs.org/comment/1775881/","msgid":"<59CAC8F4.2040503@linaro.org>","list_archive_url":null,"date":"2017-09-26T21:39:00","subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for\n\ttwo steps mappings","submitter":{"id":47236,"url":"http://patchwork.ozlabs.org/api/people/47236/","name":"Hanjun Guo","email":"hanjun.guo@linaro.org"},"content":"On 09/22/2017 08:53 PM, Lorenzo Pieralisi wrote:\n> On Thu, Sep 21, 2017 at 09:17:17PM +0800, Hanjun Guo wrote:\n>> From: Hanjun Guo \n>>\n>> IORT revision C introduced SMMUv3 MSI support which adding a\n>> device ID mapping index in SMMUv3 sub table, to get the SMMUv3\n>> device ID mapping for the output ID (dev ID for ITS) and the\n>> link to which ITS.\n>>\n>> So if a platform supports SMMUv3 MSI for control interrupt,\n>> there will be a additional single map entry under SMMU, this\n>> will not introduce any difference for devices just use one\n>> step map to get its output ID and parent (ITS or SMMU), such\n>> as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to\n>> do the special handling for two steps map case such as\n>> PCI/NC--->SMMUv3--->ITS.\n>>\n>> Take a PCI hostbridge for example,\n>>\n>> |----------------------|\n>> | Root Complex Node |\n>> |----------------------|\n>> | map entry[x] |\n>> |----------------------|\n>> | id value |\n>> | output_reference |\n>> |---|------------------|\n>> |\n>> | |----------------------|\n>> |-->| SMMUv3 |\n>> |----------------------|\n>> | SMMU dev ID |\n>> | mapping index 0 |\n>> |----------------------|\n>> | map entry[0] |\n>> |----------------------|\n>> | id value |\n>> | output_reference-----------> ITS 1 (SMMU MSI domain)\n>> |----------------------|\n>> | map entry[1] |\n>> |----------------------|\n>> | id value |\n>> | output_reference-----------> ITS 2 (PCI MSI domain)\n>> |----------------------|\n>>\n>> When the SMMU dev ID mapping index is 0, there is entry[0]\n>> to map to a ITS, we need to skip that map entry for PCI\n>> or NC (named component), or we may get the wrong ITS parent.\n>\n> We do skip it because it is a single mapping that it is currently\n> not allowed for SMMUv3 components, right ?\n>\n> Ok, we barf with a printk log message if we encounter such mapping\n> but the mapping won't resolve to the SMMUv3 MSI in the current\n> kernel.\n\nThis is not clear in the spec, maybe we also need to update the IORT\nspec about it.\n\nThanks\nHanjun","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"G96EWDJh\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"SOyxh8s1\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1vVZ3B9Tz9t3Z\n\tfor ;\n\tWed, 27 Sep 2017 07:39:34 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwxZg-00033B-7w; Tue, 26 Sep 2017 21:39:28 +0000","from mail-pg0-x231.google.com ([2607:f8b0:400e:c05::231])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dwxZc-0002g3-6L for linux-arm-kernel@lists.infradead.org;\n\tTue, 26 Sep 2017 21:39:26 +0000","by mail-pg0-x231.google.com with SMTP id i195so6619822pgd.9\n\tfor ;\n\tTue, 26 Sep 2017 14:39:03 -0700 (PDT)","from [172.20.3.46] ([70.35.39.2])\n\tby smtp.googlemail.com with ESMTPSA id\n\th1sm18611393pgf.54.2017.09.26.14.39.01\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 26 Sep 2017 14:39:02 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:References:Subject:To:MIME-Version:From:\n\tDate:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=TVxpulLPu5xCadJHXs9M7gowaDjxC3s6Fc6HL1loeAo=;\n\tb=G96EWDJh4aMX34FVLGLZQR6wU\n\txxMfUN8gyvJ/l8s9O/6zFhawVaAgUYnDwtFh5a4Sd3ZiYPFokr1nDbDUWd/TIZgxlv/BRR2AH/hwB\n\tfgRuzGDqR4U6fbiokfxNLKkhAQUfbleM4g/xeOnWa/ZfrkNwE72ZegnCCJHDfOBw1aI+d55R8Npu5\n\t+0VGW8iYwp8SsSCg+r/52azFpxT2no3IZDui2BMtwo/LiMHmdV6hmpsYJmBddMmjSLJ9WOX/bLbLp\n\twt9bcRmTp6AKzHkcogpzu5FN39/uRwijW/u+9Pbl2khsA6IugXHlCAz/LGqtrLnyfe8p4b8ROpFz7\n\tj5lSrOsqg==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=message-id:date:from:user-agent:mime-version:to:cc:subject\n\t:references:in-reply-to:content-transfer-encoding;\n\tbh=owpXIxpjYtt/1VnV3Zr3PSQf4241jpawf1lz3UXne3U=;\n\tb=SOyxh8s1VQvzJxiJaTGUK6WwvF8ZrriJimEuYxT6FPl6ZwNH4u7wkjI2gztSRqJN0D\n\tcG19kAaxqUWxWnj5rwYjh0yCEcSmkgdlsvk61eeitrFE2ofSfqgSKAbkR6d1AZbp8Mb0\n\tHHQZNZzTQ34lyRlh6jnc/5nD4CjzkFNGZzchc="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:date:from:user-agent:mime-version:to\n\t:cc:subject:references:in-reply-to:content-transfer-encoding;\n\tbh=owpXIxpjYtt/1VnV3Zr3PSQf4241jpawf1lz3UXne3U=;\n\tb=dhseTid3z/bh4cSjz5YOwDL2lU5MFY7gdOUjS+dtCJM+755iuOQK+PF8yv9coJtKkF\n\tf3B4IvSvG/E/8g7dAWC6e6DL80mKPdhksA3YNuJnEpxGLSLDQEUvPnllGH4V7DTEAyoV\n\ttSwaaAbWGqYntOg+GEc9Qv+Zeh8RShZfMiXxlBdRnxp44XcFD4Vi7YInoaYN0AVQmI6D\n\t/mru6yOXP6A5N64tgHFJEDDP96NYdoDI/mY9/o1PDpwIXsXyzD4Fy4VfrEymCktlgCxR\n\tuNAe/05BAJchz/Ca4u4n8Ar18EP8tfOXwTwKUQKcujWIAeTTo+OYxbAO7Q7fVmJhx5S1\n\t4dgQ==","X-Gm-Message-State":"AHPjjUgFHxpkDGt3zNdClPXXKrn1FFS/zHtHO4ALgYBScqrAS159vZFi\n\ts7OJtDQugp0F5NHRgW5tNPF2RQ==","X-Google-Smtp-Source":"AOwi7QByeG5WhaY/ZfpEkdVe2PS2zpfflyl4kINh2vMCO8G3E4MqyFDugaEm4EzRppdd5NuJQ7f2pA==","X-Received":"by 10.84.248.66 with SMTP id e2mr12107778pln.384.1506461943311; \n\tTue, 26 Sep 2017 14:39:03 -0700 (PDT)","Message-ID":"<59CAC8F4.2040503@linaro.org>","Date":"Wed, 27 Sep 2017 05:39:00 +0800","From":"Hanjun Guo ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Thunderbird/31.7.0","MIME-Version":"1.0","To":"Lorenzo Pieralisi , \n\tHanjun Guo ","Subject":"Re: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for\n\ttwo steps mappings","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-4-git-send-email-guohanjun@huawei.com>\n\t<20170922125334.GC3475@red-moon>","In-Reply-To":"<20170922125334.GC3475@red-moon>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170926_143924_272140_9F24455B ","X-CRM114-Status":"GOOD ( 18.54 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c05:0:0:0:231 listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Robin Murphy ,\n\tlinux-arm-kernel@lists.infradead.org","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1775963,"web_url":"http://patchwork.ozlabs.org/comment/1775963/","msgid":"<59CAF20C.6050403@linaro.org>","list_archive_url":null,"date":"2017-09-27T00:34:20","subject":"Re: [RFC PATCH v2 4/4] ACPI: IORT: SMMUv3 nodes MSI support","submitter":{"id":47236,"url":"http://patchwork.ozlabs.org/api/people/47236/","name":"Hanjun Guo","email":"hanjun.guo@linaro.org"},"content":"On 09/22/2017 09:07 PM, Lorenzo Pieralisi wrote:\n> On Thu, Sep 21, 2017 at 09:17:18PM +0800, Hanjun Guo wrote:\n>> From: Lorenzo Pieralisi \n>>\n>> Since we make single mappings valid for SMMUv3 (and PMCG), also\n>> we have a mapping index for SMMUv3 MSI, we can directly use that\n>> index to get the map entry, then retrieve dev ID and ITS parent\n>> to add SMMUv3 MSI support.\n>>\n>> Introduce a new API iort_set_device_domain() to find the MSI domain\n>> for an SMMUv3 (or any other IORT table node) to reduce the complex\n>> of doing that via acpi_configure_pmsi_domain(), then reuse the\n>> iort_node_get_id() to get the dev id for SMMU MSI.\n>>\n>> Signed-off-by: Lorenzo Pieralisi \n>> Signed-off-by: Hanjun Guo \n>> ---\n>> drivers/acpi/arm64/iort.c | 99 ++++++++++++++++++++++++++++++++++++++---------\n>> 1 file changed, 81 insertions(+), 18 deletions(-)\n>>\n>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n>> index 269959e..bbab2ab 100644\n>> --- a/drivers/acpi/arm64/iort.c\n>> +++ b/drivers/acpi/arm64/iort.c\n>> @@ -357,7 +357,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n>>\n>> \tif (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {\n>> \t\tif (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||\n>> -\t\t node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {\n>> +\t\t node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||\n>> +\t\t node->type == ACPI_IORT_NODE_SMMU_V3) {\n>> \t\t\t*id_out = map->output_base;\n>> \t\t\treturn parent;\n>> \t\t}\n>> @@ -366,8 +367,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n>> \treturn NULL;\n>> }\n>>\n>> -static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n>> -\t\t\t\t\t u32 *index)\n>> +static int iort_get_id_mapping_index(struct acpi_iort_node *node,\n>> +\t\t\t\t u32 *index)\n>> {\n>> \tstruct acpi_iort_smmu_v3 *smmu;\n>>\n>> @@ -378,20 +379,28 @@ static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node,\n>> \tif (node->revision < 1)\n>> \t\treturn -EINVAL;\n>>\n>> -\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n>> -\t/* if any of the gsi for control interrupts is not 0, ignore the MSI */\n>> -\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n>> -\t || smmu->sync_gsiv)\n>> -\t\treturn -EINVAL;\n>> +\tswitch (node->type) {\n>> +\tcase ACPI_IORT_NODE_SMMU_V3:\n>> +\t\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n>> +\t\t/*\n>> +\t\t * if any of the gsi for control interrupts is not 0,\n>> +\t\t * ignore the MSI\n>> +\t\t */\n>> +\t\tif (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv\n>> +\t\t || smmu->sync_gsiv)\n>> +\t\t\treturn -EINVAL;\n>>\n>> -\tif (smmu->id_mapping_index >= node->mapping_count) {\n>> -\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n>> -\t\t node, node->type);\n>> +\t\tif (smmu->id_mapping_index >= node->mapping_count) {\n>> +\t\t\tpr_err(FW_BUG \"[node %p type %d] ID mapping index overflows valid mappings\\n\",\n>> +\t\t\t node, node->type);\n>> +\t\t\treturn -EINVAL;\n>> +\t\t}\n>> +\n>> +\t\t*index = smmu->id_mapping_index;\n>> +\t\treturn 0;\n>> +\tdefault:\n>> \t\treturn -EINVAL;\n>> \t}\n>> -\n>> -\t*index = smmu->id_mapping_index;\n>> -\treturn 0;\n>> }\n>>\n>> static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n>> @@ -431,7 +440,7 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,\n>> \t\t * associated ID map for single mapping cases.\n>> \t\t */\n>> \t\tif (node->type == ACPI_IORT_NODE_SMMU_V3)\n>\n> I wanted to use:\n>\n> iort_get_id_mapping_index()\n>\n> so that the node type check is done *in* that function and you do\n> not need to check it here.\n>\n>> -\t\t\tret = iort_get_smmu_v3_id_mapping_index(node, &index);\n>> +\t\t\tret = iort_get_id_mapping_index(node, &index);\n>>\n>> \t\t/* Do the ID translation */\n>> \t\tfor (i = 0; i < node->mapping_count; i++, map++) {\n>> @@ -555,9 +564,18 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)\n>> \tif (!node)\n>> \t\treturn -ENODEV;\n>>\n>> -\tfor (i = 0; i < node->mapping_count; i++) {\n>> -\t\tif (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))\n>> -\t\t\treturn 0;\n>> +\tif (node->type == ACPI_IORT_NODE_SMMU_V3) {\n>\n> Ditto.\n>\n>> +\t\tu32 index;\n>> +\n>> +\t\tif (!iort_get_id_mapping_index(node, &index)) {\n>> +\t\t\tif (iort_node_get_id(node, dev_id, index))\n>> +\t\t\t\treturn 0;\n>> +\t\t}\n>> +\t} else {\n>> +\t\tfor (i = 0; i < node->mapping_count; i++) {\n>> +\t\t\tif (iort_node_map_platform_id(node, dev_id, IORT_MSI_TYPE, i))\n>> +\t\t\t\treturn 0;\n>> +\t\t}\n>> \t}\n>>\n>> \treturn -ENODEV;\n>> @@ -620,6 +638,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)\n>> \treturn irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);\n>> }\n>\n> All changes above can be squashed with patch 3.\n>\n>> +static void iort_set_device_domain(struct device *dev,\n>> +\t\t\t\t struct acpi_iort_node *node)\n>> +{\n>> +\tstruct acpi_iort_its_group *its;\n>> +\tstruct acpi_iort_node *msi_parent;\n>> +\tstruct acpi_iort_id_mapping *map;\n>> +\tstruct fwnode_handle *iort_fwnode;\n>> +\tstruct irq_domain *domain;\n>> +\tint ret, index;\n>> +\n>> +\tret = iort_get_id_mapping_index(node, &index);\n>> +\tif (ret < 0)\n>> +\t\treturn;\n>> +\n>> +\tmap = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,\n>> +\t\t\t node->mapping_offset + index * sizeof(*map));\n>> +\n>> +\t/* Firmware bug! */\n>> +\tif (!map->output_reference ||\n>> +\t !(map->flags & ACPI_IORT_ID_SINGLE_MAPPING)) {\n>> +\t\tpr_err(FW_BUG \"[node %p type %d] Invalid MSI mapping\\n\",\n>> +\t\t node, node->type);\n>> +\t\treturn;\n>> +\t}\n>> +\n>> +\tmsi_parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,\n>> +\t\t\t\t map->output_reference);\n>> +\n>> +\tif (!msi_parent || msi_parent->type != ACPI_IORT_NODE_ITS_GROUP)\n>> +\t\treturn;\n>> +\n>> +\t/* Move to ITS specific data */\n>> +\tits = (struct acpi_iort_its_group *)msi_parent->node_data;\n>> +\n>> +\tiort_fwnode = iort_find_domain_token(its->identifiers[0]);\n>> +\tif (!iort_fwnode)\n>> +\t\treturn;\n>> +\n>> +\tdomain = irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);\n>> +\tif (domain)\n>> +\t\tdev_set_msi_domain(dev, domain);\n>> +}\n>> +\n>> /**\n>> * iort_get_platform_device_domain() - Find MSI domain related to a\n>> * platform device\n>> @@ -1246,6 +1307,8 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)\n>> \t/* Configure DMA for the page table walker */\n>> \tacpi_dma_configure(&pdev->dev, attr);\n>>\n>> +\tiort_set_device_domain(&pdev->dev, node);\n>> +\n>\n> ..and then you introduce iort_set_device_domain() and use it in a\n> separate patch.\n>\n> With these changes I think we are ready to queue the series.\n\nUpdated already, will send a new version soon.\n\nThanks\nHanjun","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"KiAt7h7H\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"RuUOG38g\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y1zNw3VBgz9t3B\n\tfor ;\n\tWed, 27 Sep 2017 10:34:56 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx0JQ-00084j-52; Wed, 27 Sep 2017 00:34:52 +0000","from mail-pf0-x236.google.com ([2607:f8b0:400e:c00::236])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dx0JK-0007pI-I9 for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 00:34:49 +0000","by mail-pf0-x236.google.com with SMTP id m63so6370402pfk.7\n\tfor ;\n\tTue, 26 Sep 2017 17:34:25 -0700 (PDT)","from [172.20.3.46] ([70.35.39.2])\n\tby smtp.googlemail.com with ESMTPSA id\n\tq13sm16228409pgt.87.2017.09.26.17.34.23\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tTue, 26 Sep 2017 17:34:24 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:References:Subject:To:MIME-Version:From:\n\tDate:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=bbO6J4c5Zj1iNc7vcHEA/5R8TPpnKr7YPgyyjskQJvU=;\n\tb=KiAt7h7HahbZFpGa9cVMIRvEa\n\tFgFJCxoj5c+kzIeoOIBFfe1s5QidtH5zPhGqsXALWHFnC5kNdUlb7ddsPINWj5PllrbnQ8LLSlqjU\n\tGkd+RyjoMLhro6AnvagQbPtyOa5vvyZcrYOW4//NxqoOv27+rOhFbUlKUFrT3UPHABdyJ+t/wIXXl\n\tnrA8/3+M1M8xK46nlWsPMDCaYaMub7m9oo/7KO2OvDzTToGBwNV5PiefLkkpBa8uQHAsCy6mk2cCV\n\tO+02ubmZqCVWJHoCCJ6nqkoeHbURQOae/dpiZU/nXHmSBdXUGXrYZre17sG5BOFAqjvSdeOEXPFKV\n\tAhAkBtILA==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=message-id:date:from:user-agent:mime-version:to:cc:subject\n\t:references:in-reply-to:content-transfer-encoding;\n\tbh=DmLEurT4kN3l8lAYaT2YASpRv3cAdyHNcIH9bSb7lVo=;\n\tb=RuUOG38g+p4HaFulS9uf+aaqeo+BuetxCQg+FtdDNLZXKRecA7cCYIgg5gyTwraOEr\n\thG5nSP2eXgbZFu4m6beOd342DBWPwZX8ykhtJaYRLFWpjEWcNLDh3c/Uf+H2LWS4wI37\n\tuVJTZdaxSdr7YhFHe5DuEdHNR7O2xLaCEntg4="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:date:from:user-agent:mime-version:to\n\t:cc:subject:references:in-reply-to:content-transfer-encoding;\n\tbh=DmLEurT4kN3l8lAYaT2YASpRv3cAdyHNcIH9bSb7lVo=;\n\tb=oURi5k5jnKCn+a1DY2pUUkGUrvpVDUAxQ7IvK5w0rrWgiLMlI1DIXIYJkJjSROxwtk\n\tQL2S8u/EGxXLNXX4k03dkJBLV56KZB+xTFqrYwQ/bDZDPJGiDBtAAlqm1kXPugzww956\n\tp9pt5dElhXPl+i9hwlvX8t1qJ67MtB48GdPsddwn7sTiqqHf6Y2eOnNQmG3mJqhGYNja\n\tvvLLZ+RfZ9IuHxwBUnyJ0ok2JrdVNtXPbbNRzMQzzqD7LIh+SVFziAaOsWZPVEXbSGjh\n\tD7SqzCr6TqH6SvhdQEBC7uu1LLnm/rS55OuhWsEQfdkXNcLOXgitQ+cOnBeUhBx8qMfn\n\tnPtA==","X-Gm-Message-State":"AHPjjUg97Z9ggVNHl1qf5pvJiAcc37FxIg/Zhk9ibVXt0NT9qXxyI1wk\n\t0xXmKxdZx6oDmf08AOLru7PhTQ==","X-Google-Smtp-Source":"AOwi7QAnDYxpIFiK48Z8lOh5hNsZJhYgMGC1td646JxJAFleBclv72zMBP4tGfCiyC84icSVm5Vtsw==","X-Received":"by 10.99.109.134 with SMTP id\n\ti128mr12769544pgc.345.1506472464566; \n\tTue, 26 Sep 2017 17:34:24 -0700 (PDT)","Message-ID":"<59CAF20C.6050403@linaro.org>","Date":"Wed, 27 Sep 2017 08:34:20 +0800","From":"Hanjun Guo ","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:31.0) Gecko/20100101 Thunderbird/31.7.0","MIME-Version":"1.0","To":"Lorenzo Pieralisi , \n\tHanjun Guo ","Subject":"Re: [RFC PATCH v2 4/4] ACPI: IORT: SMMUv3 nodes MSI support","References":"<1505999838-52530-1-git-send-email-guohanjun@huawei.com>\n\t<1505999838-52530-5-git-send-email-guohanjun@huawei.com>\n\t<20170922130741.GD3475@red-moon>","In-Reply-To":"<20170922130741.GD3475@red-moon>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170926_173446_810993_7AD39007 ","X-CRM114-Status":"GOOD ( 26.22 )","X-Spam-Score":"-2.0 (--)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-2.0 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c00:0:0:0:236 listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"\"Rafael J. Wysocki\" ,\n\tMarc Zyngier , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Robin Murphy ,\n\tlinux-arm-kernel@lists.infradead.org","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]