[{"id":1776382,"web_url":"http://patchwork.ozlabs.org/comment/1776382/","msgid":"<20170927135449.GA11347@red-moon>","list_archive_url":null,"date":"2017-09-27T13:54:49","subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"Hi Hanjun,\n\nOn Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:\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\nIs this actually true ? I think that currently we would simply skip\nthe entry and print an error log but we can't get a wrong ITS parent.\n\nI am rewriting this commit (I will probably split it), it is doing the\nright thing but the commit log is stale (probably caused by code\nreshuffling).\n\nThanks,\nLorenzo\n\n> Introduce iort_get_id_mapping_index() to get the index then\n> skip the map entry in iort_node_map_id(), also to get the\n> dev ID directly for iort_pmsi_get_dev_id() for ITS platform\n> MSI preparation.\n> \n> Signed-off-by: Hanjun Guo \n> ---\n> drivers/acpi/arm64/iort.c | 64 +++++++++++++++++++++++++++++++++++++++++++----\n> 1 file changed, 59 insertions(+), 5 deletions(-)\n> \n> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n> index db71d7f..1c1160e 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,6 +367,40 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n> \treturn NULL;\n> }\n> \n> +static int iort_get_id_mapping_index(struct acpi_iort_node *node)\n> +{\n> +\tstruct acpi_iort_smmu_v3 *smmu;\n> +\n> +\tswitch (node->type) {\n> +\tcase ACPI_IORT_NODE_SMMU_V3:\n> +\t\t/*\n> +\t\t * SMMUv3 dev ID mapping index was introdueced in revision 1\n> +\t\t * table, not available in revision 0\n> +\t\t */\n> +\t\tif (node->revision < 1)\n> +\t\t\treturn -EINVAL;\n> +\n> +\t\tsmmu = (struct acpi_iort_smmu_v3 *)node->node_data;\n> +\t\t/*\n> +\t\t * ID mapping index is only ignored if all interrupts are\n> +\t\t * GSIV based\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> +\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\treturn smmu->id_mapping_index;\n> +\tdefault:\n> +\t\treturn -EINVAL;\n> +\t}\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 +410,7 @@ 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, index;\n> \n> \t\tif (IORT_TYPE_MASK(node->type) & type_mask) {\n> \t\t\tif (id_out)\n> @@ -396,8 +431,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, error value\n> +\t\t * returned for index will be an invalid value in practical.\n> +\t\t */\n> +\t\tindex = iort_get_id_mapping_index(node);\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 (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> @@ -507,16 +553,24 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)\n> */\n> int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)\n> {\n> -\tint i;\n> +\tint i, index;\n> \tstruct acpi_iort_node *node;\n> \n> \tnode = iort_find_dev_node(dev);\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> +\tindex = iort_get_id_mapping_index(node);\n> +\t/* if there is a valid index, go get the dev_id directly */\n> +\tif (index >= 0) {\n> +\t\tif (iort_node_get_id(node, dev_id, index))\n> \t\t\treturn 0;\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,\n> +\t\t\t\t\t\t IORT_MSI_TYPE, i))\n> +\t\t\t\treturn 0;\n> +\t\t}\n> \t}\n> \n> \treturn -ENODEV;\n> -- \n> 1.9.1\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=\"Vi0bfyz2\"; 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 3y2KLk0qsnz9tXw\n\tfor ;\n\tThu, 28 Sep 2017 00:04:14 +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 1dxCwY-0007Yn-Sb; Wed, 27 Sep 2017 14:04:06 +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 1dxClP-0002yg-5U for linux-arm-kernel@lists.infradead.org;\n\tWed, 27 Sep 2017 13:52:36 +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 B35071596;\n\tWed, 27 Sep 2017 06:52:18 -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\t16D363F3E1; Wed, 27 Sep 2017 06:52:16 -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=zOeJ5tQdvawuqU5u0sSFUHpQBv1a6JhVd94N9Jsf+JY=;\n\tb=Vi0bfyz2QT0HVd\n\th+tdBJjpBQiHJ0PUYs20VvxNVtmWoJJEiA8xvosd+ReNP4e2b2f5Z1u9jQcBXK1VMG5Ih6HSJoftk\n\tH7MOENmGPvVXIh4vnb4YNSJxvLqCFPcgukuLSsdHZqw+E1EgRtjGB9AF2zjKiNiCZeTo/VVF4EwSO\n\t5v6YT4b7zaJVPyCSvArC/DfuxReyqGD56uepex9Qr/U+JB8DYf+D8kEY1TJDcpSxGHRAyDQFwQxPD\n\tgru3sHCAWTLxrMFuoxkNzsYwDd9GD516/McGUMC8rBYLYUF3t4UnSiZPNyXox0TynVep9Is8IT4Ji\n\tnRRwuzaPkdKnT5ZHVJJw==;","Date":"Wed, 27 Sep 2017 14:54:49 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","Message-ID":"<20170927135449.GA11347@red-moon>","References":"<1506475215-2731-1-git-send-email-hanjun.guo@linaro.org>\n\t<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>","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-20170927_065235_223950_29AD7258 ","X-CRM114-Status":"GOOD ( 26.66 )","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":"Marc Zyngier ,\n\t\"Rafael J. Wysocki\" , linuxarm@huawei.com,\n\tlinux-acpi@vger.kernel.org, Lv Zheng ,\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":1783445,"web_url":"http://patchwork.ozlabs.org/comment/1783445/","msgid":"","list_archive_url":null,"date":"2017-10-10T06:47:53","subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","submitter":{"id":47236,"url":"http://patchwork.ozlabs.org/api/people/47236/","name":"Hanjun Guo","email":"hanjun.guo@linaro.org"},"content":"Hi Lorenzo,\n\nSorry for the late reply, holidays in China for the past week.\n\nAt 2017/9/27 21:54, Lorenzo Pieralisi wrote:\n> Hi Hanjun,\n>\n> On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:\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> Is this actually true ? I think that currently we would simply skip\n> the entry and print an error log but we can't get a wrong ITS parent.\n\nSo the only valid single mapping under type SMMUv3 is SMMUv3's dev id\nmapping, we need to fix the IORT spec as well.\n\n>\n> I am rewriting this commit (I will probably split it), it is doing the\n> right thing but the commit log is stale (probably caused by code\n> reshuffling).\n\nDo I need to resend another version, or you can help to update it?\nplease let me know.\n\nBy the way, this patch set was tested on Hisilicon Hip08 with MSI\nfor SMMU, and it works fine.\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=\"jUsYfIJo\"; \n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"PFV1Ws0x\"; 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 3yB73w0VTWz9t39\n\tfor ;\n\tTue, 10 Oct 2017 17:48:28 +1100 (AEDT)","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 1e1oKx-0004Fl-UF; Tue, 10 Oct 2017 06:48:19 +0000","from mail-qt0-x22a.google.com ([2607:f8b0:400d:c0d::22a])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e1oKu-0004Dd-1F for linux-arm-kernel@lists.infradead.org;\n\tTue, 10 Oct 2017 06:48:17 +0000","by mail-qt0-x22a.google.com with SMTP id f15so48370930qtf.7\n\tfor ;\n\tMon, 09 Oct 2017 23:47:55 -0700 (PDT)","by 10.12.170.196 with HTTP; Mon, 9 Oct 2017 23:47:53 -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:To:Subject:Message-ID:Date:From:\n\tReferences:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=uK4Bp8Wljc4yCN38JQe9P5HxIF2Hh0dUSak16j031eE=;\n\tb=jUsYfIJoa3YzD1\n\tUQwzpDy2aMC5n/9iADn/7am/cYJPknrZPCkdK+21GwfNXToWOv3/U5iRmINK5KWLYuoCuDlY8PK/B\n\tJIWc+Gdh38IGmyg/ZoNjlUeLn6bf99e8SV8k92u3QSPOc3r7WxdzmiX+enFvvoyhyGOneAw0dJZSW\n\t7t/byXA1kAiXyxBzdXLLid0mJeIi5nuR5YXCT3WufUkXW+u7h82LsACzi9sqEvnglN9aKUiS6/ONn\n\tnnJ12omG/DUAqkhxRjaUtVC1eo7545tQiLMvKImy9yPtP7rnR1W8ZEu+fXS0GP1R+j1+eoMBH5zVf\n\tOCUOEGfGE+HUpE5Ae5XA==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=JQgEXSvCQzawgaYV5SsuOodo24XTLwWy51xv5bIjoDs=;\n\tb=PFV1Ws0xoTOkqkC+LOTjWuRyblYbUyZFCFpXp28qII8c0ZuAzoVcivHvMA03MbV4QV\n\tvb5atmlcH9G7oBK980GcMtqmIXZ9YlkbKi6Wa6AMqZZBuCn0CeGOV8KI/nv4T0DmIMv+\n\tWgxszjMTWXaAvb3WPetLmWhAWU3zwg+L7ODFA="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=JQgEXSvCQzawgaYV5SsuOodo24XTLwWy51xv5bIjoDs=;\n\tb=Y6g8iUb8sfRX0EjXi0qmiXGLR5bS7Eu6ygXZJgAVc2/IKNeTnGFMogZOt/LDKWumkk\n\tEeSuEe8/X76aISrXJYLE2wtgVIMtVaHgmND8Ww7RjHzeKeipzDZW0fqmhEoclA42o7NG\n\tAIizhj8LngvNunK8SWnKmqEAKoBsnOdiMWS+FaT20cl4CNB48yQ3Zhlh6lxmJz50Y3Qh\n\tcp5yAnvCJ3F2g5GpDB0sJr+dkPJqdutG5jM8iRt1Jrt6K0MhoWbC/vybjJAd6dak1U3B\n\tr+rbxdScsgnrJCz8z/eEJtM/CHZzebsJQk+NAmlPwd0LGvG1vD4M7HRIiprb8BrED0yE\n\te7ag==","X-Gm-Message-State":"AMCzsaVOzYZ5fNm8pze/2CjgmYyKh2m/HSf5RlMbEsn7+fkn9GLTFvJT\n\tPJYaZLQenI+D2oFL1b2EH7XI5QtgKeLbQVgEqsxt6Q==","X-Google-Smtp-Source":"AOwi7QC4MD9aNqy1rsShUKbg0RJMf/q5OinfQKAFCdtVcMWLv5DK5RmxZEqqimh9szBCNfTe8Xt4vGfNNbnJ2o788m4=","X-Received":"by 10.200.42.11 with SMTP id k11mr4703306qtk.273.1507618074174; \n\tMon, 09 Oct 2017 23:47:54 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170927135449.GA11347@red-moon>","References":"<1506475215-2731-1-git-send-email-hanjun.guo@linaro.org>\n\t<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>\n\t<20170927135449.GA11347@red-moon>","From":"Hanjun Guo ","Date":"Tue, 10 Oct 2017 14:47:53 +0800","Message-ID":"","Subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","To":"Lorenzo Pieralisi ","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171009_234816_344714_82EB0A44 ","X-CRM114-Status":"GOOD ( 17.43 )","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:400d:c0d:0:0:0:22a 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 ,\n\t\"Rafael J. Wysocki\" , Linuxarm , \n\t\"linux-acpi@vger.kernel.org\" ,\n\tLv Zheng , Robin Murphy ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t","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":1783540,"web_url":"http://patchwork.ozlabs.org/comment/1783540/","msgid":"<20171010092036.GA8507@red-moon>","list_archive_url":null,"date":"2017-10-10T09:20:36","subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Tue, Oct 10, 2017 at 02:47:53PM +0800, Hanjun Guo wrote:\n> Hi Lorenzo,\n> \n> Sorry for the late reply, holidays in China for the past week.\n> \n> At 2017/9/27 21:54, Lorenzo Pieralisi wrote:\n> > Hi Hanjun,\n> >\n> > On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:\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> > Is this actually true ? I think that currently we would simply skip\n> > the entry and print an error log but we can't get a wrong ITS parent.\n> \n> So the only valid single mapping under type SMMUv3 is SMMUv3's dev id\n> mapping, we need to fix the IORT spec as well.\n> \n> >\n> > I am rewriting this commit (I will probably split it), it is doing the\n> > right thing but the commit log is stale (probably caused by code\n> > reshuffling).\n> \n> Do I need to resend another version, or you can help to update it?\n> please let me know.\n\nI reworked the patches, you can repost/retest them I made them available\nin the branch below, we will have to add a guard around ACPICA smmu\nstruct (unfortunately I think we will have to use the ACPICA version as\na guard) or I can ask Rafael to pull the series if ACPICA goes via ACPI\ntree (and your patch made it into the release - I will check ACPICA\nupstream).\n\ngit://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iort/smmu-msi-for-4.15","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=\"XxabXi3L\"; 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 3yBBSK113Kz9t6Y\n\tfor ;\n\tTue, 10 Oct 2017 20:21:21 +1100 (AEDT)","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 1e1qiz-00027b-7W; Tue, 10 Oct 2017 09:21:17 +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 1e1qip-0001za-B5 for linux-arm-kernel@lists.infradead.org;\n\tTue, 10 Oct 2017 09:21:15 +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 05D0E80D;\n\tTue, 10 Oct 2017 02:20:47 -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\t7FDC53F483; Tue, 10 Oct 2017 02:20:45 -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=R92QextWKqQ4yz5hPJuwA1uTRzzrcnIXbgVzqqQ3+4A=;\n\tb=XxabXi3LHqlhUR\n\twTFDT03kfIOwXqVLtOT2FBNaYwF/WhesxT7k06H1aIMhBiCbIbt9o/ql/43II33QLmEWRfONVdOuF\n\tDiXXdRmPbQAdTZ6ES1EAtzThsWZxIyiVPMR4OjCCvF7jqvrPxcc9Gelt8e5lz2l1W/rIx+UWBJqJn\n\tbncXGYuuapAkDTABNAyg76iY26iUcUtfc7A1gHA0T20apsZgj6Hb7j1g+tA/6AarF3E9+U5XGX5/+\n\tIo+C5V2GHlPl75b0Ne+dRdK/90ScBM1hqYvJWx6cIAGqrtQ4KOJwtb+T+W1nFTyhOUWW5cJ0lW3zV\n\tOMRzrghO0vFBeICsgfLA==;","Date":"Tue, 10 Oct 2017 10:20:36 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","Message-ID":"<20171010092036.GA8507@red-moon>","References":"<1506475215-2731-1-git-send-email-hanjun.guo@linaro.org>\n\t<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>\n\t<20170927135449.GA11347@red-moon>\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","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-20171010_022107_455950_6A1A75E2 ","X-CRM114-Status":"GOOD ( 21.60 )","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":"Marc Zyngier ,\n\t\"Rafael J. Wysocki\" , Linuxarm , \n\t\"linux-acpi@vger.kernel.org\" ,\n\tLv Zheng , Robin Murphy ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t","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":1784296,"web_url":"http://patchwork.ozlabs.org/comment/1784296/","msgid":"<59DDAB72.7070605@huawei.com>","list_archive_url":null,"date":"2017-10-11T05:26:10","subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","submitter":{"id":15909,"url":"http://patchwork.ozlabs.org/api/people/15909/","name":"Hanjun Guo","email":"guohanjun@huawei.com"},"content":"On 2017/10/10 17:20, Lorenzo Pieralisi wrote:\n> On Tue, Oct 10, 2017 at 02:47:53PM +0800, Hanjun Guo wrote:\n>> Hi Lorenzo,\n>>\n>> Sorry for the late reply, holidays in China for the past week.\n>>\n>> At 2017/9/27 21:54, Lorenzo Pieralisi wrote:\n>>> Hi Hanjun,\n>>>\n>>> On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:\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>>> Is this actually true ? I think that currently we would simply skip\n>>> the entry and print an error log but we can't get a wrong ITS parent.\n>> So the only valid single mapping under type SMMUv3 is SMMUv3's dev id\n>> mapping, we need to fix the IORT spec as well.\n>>\n>>> I am rewriting this commit (I will probably split it), it is doing the\n>>> right thing but the commit log is stale (probably caused by code\n>>> reshuffling).\n>> Do I need to resend another version, or you can help to update it?\n>> please let me know.\n> I reworked the patches, you can repost/retest them I made them available\n> in the branch below, we will have to add a guard around ACPICA smmu\n> struct (unfortunately I think we will have to use the ACPICA version as\n> a guard) or I can ask Rafael to pull the series if ACPICA goes via ACPI\n> tree (and your patch made it into the release - I will check ACPICA\n> upstream).\n\nBob already merged my pull request yesterday, I think it will be ready for\nacpica release for this month.\n\n>\n> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iort/smmu-msi-for-4.15\n>\n\nThanks! I will retest then repost.\n\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\n\theader.b=\"aStscLG5\"; 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 3yBjK00v1cz9t2V\n\tfor ;\n\tWed, 11 Oct 2017 16:31:48 +1100 (AEDT)","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 1e29cP-0007M1-5n; Wed, 11 Oct 2017 05:31:45 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1e29cL-0007FR-2p for linux-arm-kernel@lists.infradead.org;\n\tWed, 11 Oct 2017 05:31:43 +0000","from 172.30.72.58 (EHLO DGGEMS409-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DIV38203; Wed, 11 Oct 2017 13:31:01 +0800 (CST)","from [127.0.0.1] (10.177.17.188) by DGGEMS409-HUB.china.huawei.com\n\t(10.3.19.209) with Microsoft SMTP Server id 14.3.301.0;\n\tWed, 11 Oct 2017 13:26:19 +0800"],"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=aqpFCZy/Z/079qrH+HfYWJcpxtLa39HPGJnJiZCKQWE=;\n\tb=aStscLG5QVC+7w\n\twfC0Bw8vh1tQCkPJSnJD7GoWKgGxT6OiyTYa3u8/bxzAbAFB6xkuw/h1W5E7wohwfJMM0VExZgW3d\n\tAavuLMihUbuRQVfzienijo4oz/hzLLg23FNfnxuLEsl1z3E/+RqfxBfOtp5WZ4t1JE49ljrBTWhZK\n\t1QIZXoThkt2M9E1SVnrqaZjHrBd1okkIHHquwvF98Y4fNlSXC1ub2gZ96SEH0U/olBNka3/nGkDC5\n\tAv8JEF7Qg5SWCaexXCPaVpYpDji1E/abI2B6icCuma/Cs9pY088Z0SXxhAgE3Wuc9Gkxsj4PE27zm\n\tKbSP45nI+AD5kdO2SFfg==;","Subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","To":"Lorenzo Pieralisi , Hanjun Guo\n\t","References":"<1506475215-2731-1-git-send-email-hanjun.guo@linaro.org>\n\t<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>\n\t<20170927135449.GA11347@red-moon>\n\t\n\t<20171010092036.GA8507@red-moon>","From":"Hanjun Guo ","Message-ID":"<59DDAB72.7070605@huawei.com>","Date":"Wed, 11 Oct 2017 13:26:10 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101\n\tThunderbird/38.5.1","MIME-Version":"1.0","In-Reply-To":"<20171010092036.GA8507@red-moon>","X-Originating-IP":"[10.177.17.188]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020203.59DDAC95.006B, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"c3bdb2f1e3552f8ed4b19da2e182afaf","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20171010_223141_452085_1DF85A8F ","X-CRM114-Status":"GOOD ( 14.42 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 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 trust [45.249.212.190 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":"Marc Zyngier ,\n\t\"Rafael J. Wysocki\" , Linuxarm , \n\t\"linux-acpi@vger.kernel.org\" ,\n\tLv Zheng , Robin Murphy ,\n\t\"linux-arm-kernel@lists.infradead.org\"\n\t","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":1784501,"web_url":"http://patchwork.ozlabs.org/comment/1784501/","msgid":"<20171011102424.GA10795@red-moon>","list_archive_url":null,"date":"2017-10-11T10:24:24","subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Wed, Oct 11, 2017 at 01:26:10PM +0800, Hanjun Guo wrote:\n> On 2017/10/10 17:20, Lorenzo Pieralisi wrote:\n> > On Tue, Oct 10, 2017 at 02:47:53PM +0800, Hanjun Guo wrote:\n> >> Hi Lorenzo,\n> >>\n> >> Sorry for the late reply, holidays in China for the past week.\n> >>\n> >> At 2017/9/27 21:54, Lorenzo Pieralisi wrote:\n> >>> Hi Hanjun,\n> >>>\n> >>> On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:\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> >>> Is this actually true ? I think that currently we would simply skip\n> >>> the entry and print an error log but we can't get a wrong ITS parent.\n> >> So the only valid single mapping under type SMMUv3 is SMMUv3's dev id\n> >> mapping, we need to fix the IORT spec as well.\n> >>\n> >>> I am rewriting this commit (I will probably split it), it is doing the\n> >>> right thing but the commit log is stale (probably caused by code\n> >>> reshuffling).\n> >> Do I need to resend another version, or you can help to update it?\n> >> please let me know.\n> > I reworked the patches, you can repost/retest them I made them available\n> > in the branch below, we will have to add a guard around ACPICA smmu\n> > struct (unfortunately I think we will have to use the ACPICA version as\n> > a guard) or I can ask Rafael to pull the series if ACPICA goes via ACPI\n> > tree (and your patch made it into the release - I will check ACPICA\n> > upstream).\n> \n> Bob already merged my pull request yesterday, I think it will be ready for\n> acpica release for this month.\n\nThat's good, mind updating the patch series with an ACPICA guard in IORT\ncode in preparation for the pull request ?\n\n> > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iort/smmu-msi-for-4.15\n> >\n> \n> Thanks! I will retest then repost.\n\nThank you,\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=\"nx2eY/vd\"; 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 3yBqqJ6hpDz9sxR\n\tfor ;\n\tWed, 11 Oct 2017 21:25:00 +1100 (AEDT)","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 1e2EC7-0000am-Qe; Wed, 11 Oct 2017 10:24:55 +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 1e2EC2-0000UY-Jz for linux-arm-kernel@lists.infradead.org;\n\tWed, 11 Oct 2017 10:24:53 +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 4DCF8F;\n\tWed, 11 Oct 2017 03:24:30 -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\t75D243F3E1; Wed, 11 Oct 2017 03:24:28 -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=F+O/uUJZMBeHus/yuhCXjov7s3INcD4KkwFA2AlKIkA=;\n\tb=nx2eY/vd3cJZH7\n\t+z4IQTwSzwYmp+1FyPG9MlYJvIS2Qye1ZNWcoFq1UYRGFQtIZJ/vMUzauBZAf3UpwcFWwb3UQsAUv\n\thGiEh5HmbMEteMSuawPySU3JC5dCW/5tPY959rfG0ARVyIi571HfLyQcTDYeiHkVUDI2wl3U583hd\n\tqF/EK18ncZlXs2uKYZMyyUcl4QneUphZfLya5y3hPoeyoFvvvkYNa4GMaCVbeck427o3ZDw40BFIt\n\tgZRYZgfCm2XkheMucW3FUtOAPkqJxOmOlnwbaivcUdg1y/+qpw7J/dLEIkdd0nQKWefNk25A00CcD\n\t63zuCIoqeCoW9JEhLmRw==;","Date":"Wed, 11 Oct 2017 11:24:24 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","Message-ID":"<20171011102424.GA10795@red-moon>","References":"<1506475215-2731-1-git-send-email-hanjun.guo@linaro.org>\n\t<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>\n\t<20170927135449.GA11347@red-moon>\n\t\n\t<20171010092036.GA8507@red-moon> <59DDAB72.7070605@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<59DDAB72.7070605@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-20171011_032450_673409_3267F4DF ","X-CRM114-Status":"GOOD ( 22.53 )","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":"Marc Zyngier ,\n\t\"Rafael J. Wysocki\" , Linuxarm , \n\t\"linux-acpi@vger.kernel.org\" ,\n\tHanjun Guo , Robin Murphy , \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, Lv Zheng ","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":1785261,"web_url":"http://patchwork.ozlabs.org/comment/1785261/","msgid":"<20171012095017.GA19816@red-moon>","list_archive_url":null,"date":"2017-10-12T09:50:17","subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Thu, Oct 12, 2017 at 03:30:10PM +0800, Hanjun Guo wrote:\n> On 2017/10/11 18:24, Lorenzo Pieralisi wrote:\n> > On Wed, Oct 11, 2017 at 01:26:10PM +0800, Hanjun Guo wrote:\n> >> On 2017/10/10 17:20, Lorenzo Pieralisi wrote:\n> >>> On Tue, Oct 10, 2017 at 02:47:53PM +0800, Hanjun Guo wrote:\n> >>>> Hi Lorenzo,\n> >>>>\n> >>>> Sorry for the late reply, holidays in China for the past week.\n> >>>>\n> >>>> At 2017/9/27 21:54, Lorenzo Pieralisi wrote:\n> >>>>> Hi Hanjun,\n> >>>>>\n> >>>>> On Wed, Sep 27, 2017 at 09:20:14AM +0800, Hanjun Guo wrote:\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> >>>>> Is this actually true ? I think that currently we would simply skip\n> >>>>> the entry and print an error log but we can't get a wrong ITS parent.\n> >>>> So the only valid single mapping under type SMMUv3 is SMMUv3's dev id\n> >>>> mapping, we need to fix the IORT spec as well.\n> >>>>\n> >>>>> I am rewriting this commit (I will probably split it), it is doing the\n> >>>>> right thing but the commit log is stale (probably caused by code\n> >>>>> reshuffling).\n> >>>> Do I need to resend another version, or you can help to update it?\n> >>>> please let me know.\n> >>> I reworked the patches, you can repost/retest them I made them available\n> >>> in the branch below, we will have to add a guard around ACPICA smmu\n> >>> struct (unfortunately I think we will have to use the ACPICA version as\n> >>> a guard) or I can ask Rafael to pull the series if ACPICA goes via ACPI\n> >>> tree (and your patch made it into the release - I will check ACPICA\n> >>> upstream).\n> >> Bob already merged my pull request yesterday, I think it will be ready for\n> >> acpica release for this month.\n> > That's good, mind updating the patch series with an ACPICA guard in IORT\n> > code in preparation for the pull request ?\n> \n> Do you mean drop the acpica patch in this patch set and adding the code below?\n\nYes unless we find a \"smarter\" way of handling the dependency.\n\nThanks,\nLorenzo\n\n> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c\n> index 37a1b9f..a883bec 100644\n> --- a/drivers/acpi/arm64/iort.c\n> +++ b/drivers/acpi/arm64/iort.c\n> @@ -366,6 +366,7 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,\n> return NULL;\n> }\n> \n> +#if (ACPI_CA_VERSION > 0x20170929)\n> static int iort_get_id_mapping_index(struct acpi_iort_node *node)\n> {\n> struct acpi_iort_smmu_v3 *smmu;\n> @@ -399,6 +400,12 @@ static int iort_get_id_mapping_index(struct acpi_iort_node *node)\n> return -EINVAL;\n> }\n> }\n> +#else\n> +static int iort_get_id_mapping_index(struct acpi_iort_node *node)\n> +{\n> + return -EINVAL;\n> +}\n> +#endif\n> \n> Thanks\n> Hanjun\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=\"KqsitOWH\"; 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 3yCR1q597Pz9t2V\n\tfor ;\n\tThu, 12 Oct 2017 20:51:11 +1100 (AEDT)","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 1e2a8y-0000tX-If; Thu, 12 Oct 2017 09:51:08 +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 1e2a8Z-0000qq-2F for linux-arm-kernel@lists.infradead.org;\n\tThu, 12 Oct 2017 09:50:44 +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 B43C61529;\n\tThu, 12 Oct 2017 02:50:22 -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\t168523F599; Thu, 12 Oct 2017 02:50:20 -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=X/OL2+ASniSE5NugCXtLlGDKMr8IsIjd+p/ZWN57xtI=;\n\tb=KqsitOWH+JAWMQ\n\triVZKMlu4/2Ab2kOwLpEQ5IGPrrDovtv92HZDSQbqbvQNx7/hD0mU2ZN3xdwtfQ8Wsi9DSI0CcOC9\n\tZHVj2VMzLBSgj0Ul5A+cO1DBz5C5TKBvOgJXcm1oGsQBpperN4F9xeTiPy3cuo+fNcITaPWVM3E0c\n\tRO410MIuglI6UIYqgU4YaVctM5QUFv0FdlCm9NZxREk4RQ1BehSiCJkQ7TZs6PQn/VFnlzIKGT3n8\n\t9QUSwmfMqoq2nxlooXhb9rYjQMzgMDEL7eV1LrRMgSsFUl332BA1kthQp5WTPSIkWwgyLEgB7KokS\n\tLHtFIVz/+HPje5va+how==;","Date":"Thu, 12 Oct 2017 10:50:17 +0100","From":"Lorenzo Pieralisi ","To":"Hanjun Guo ","Subject":"Re: [PATCH 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps\n\tmappings","Message-ID":"<20171012095017.GA19816@red-moon>","References":"<1506475215-2731-1-git-send-email-hanjun.guo@linaro.org>\n\t<1506475215-2731-4-git-send-email-hanjun.guo@linaro.org>\n\t<20170927135449.GA11347@red-moon>\n\t\n\t<20171010092036.GA8507@red-moon> <59DDAB72.7070605@huawei.com>\n\t<20171011102424.GA10795@red-moon> <59DF1A02.9040008@huawei.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<59DF1A02.9040008@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-20171012_025043_124332_4F9EF328 ","X-CRM114-Status":"GOOD ( 25.62 )","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":"Marc Zyngier ,\n\t\"Rafael J. Wysocki\" , Linuxarm , \n\t\"linux-acpi@vger.kernel.org\" ,\n\tHanjun Guo , Robin Murphy , \n\t\"linux-arm-kernel@lists.infradead.org\"\n\t, Lv Zheng ","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"}}]