From patchwork Thu Sep 21 13:17:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 113259 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp2024914qgf; Thu, 21 Sep 2017 06:26:04 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCn1FLDJtU7HwiIGldsFn8idTqFmp+3GSl3ATU17QFX9YxvMzbtIEwO8WD38vPvmpI+LTgX X-Received: by 10.84.240.196 with SMTP id l4mr5639355plt.443.1506000364112; Thu, 21 Sep 2017 06:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506000364; cv=none; d=google.com; s=arc-20160816; b=TA+z7GZY/c+AbWmcUNFiNCom+c3UFJ3yoPvC1GK89KSZmAXaqhAeOAX5n0WU5k4CJG +/wLFwJpw1IQSQt0RtfrkmWS0EaFLyVF9XilOfgqrDXw18GDCY4gh1eTu94OAN9VASmV KYUt4ntZzJNJ6hpemu+CM6DO1oHJLXT4876RwD4toY2MAigAWzuh9x2LxYmufGH8qzFx Rjg8v5SYOoucqDLhaabn08yBTXWMuQTMsCSDzy1VCzJ1ueJ2PC7GdtkTQHOkpElwaPdV l5xXytRoNmJxW45as3VXhokICc2Ob1N6NS1WXe2isJhhu+Boge6rUCOnX311uUT/RaCe bI7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=DEPz7sYJ1+rW0KfWgpz5tyNbcM/Z0Uw2Q18R6Iw2YTA=; b=gyPmzRC3Ll4loBOfq4yC2xumJlnWTnvG/BBAJmtFgvyi0wIEK5YxNoFCgtgeNw0FLM x9dam3Hu10eC0g7Cuxcb6FZIfCdvCJyc376HwOlWY47zLJoOdy2ma0ZYGBQmOs9w44qP ZLPD04VzpApQj/9sGuT1ot53Jrj4eXRJKi9mmKUz1/iZkgWzpDHgSOEB7VVnZhtg1Rs/ xiLqmo2MlwzpzENiQ9ZD/USVTDdOTabOp+bQZKH6csp41u3DJ28KCMI6tUxu92qqlAV8 QdFJ5t5I+SpNhfbqCCOrO/uFplwHgCH2VyF2Y2gHhvnl+ENNaQ68C5fPy6zA7tr8JX7S aRMw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r6si1085604pls.393.2017.09.21.06.26.04; Thu, 21 Sep 2017 06:26:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751648AbdIUN0D (ORCPT + 7 others); Thu, 21 Sep 2017 09:26:03 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6966 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751640AbdIUN0D (ORCPT ); Thu, 21 Sep 2017 09:26:03 -0400 Received: from 172.30.72.60 (EHLO DGGEMS407-HUB.china.huawei.com) ([172.30.72.60]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DHR58235; Thu, 21 Sep 2017 21:25:26 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.301.0; Thu, 21 Sep 2017 21:25:18 +0800 From: Hanjun Guo To: Lorenzo Pieralisi , Robin Murphy CC: Marc Zyngier , "Rafael J. Wysocki" , , , , Hanjun Guo Subject: [RFC PATCH v2 1/4] ACPICA: Add SMMUv3 device ID mapping index support Date: Thu, 21 Sep 2017 21:17:15 +0800 Message-ID: <1505999838-52530-2-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 In-Reply-To: <1505999838-52530-1-git-send-email-guohanjun@huawei.com> References: <1505999838-52530-1-git-send-email-guohanjun@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59C3BDC6.01FC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 44acacff8b6a39831c645f0d5bfcf00c Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org From: Hanjun Guo SMMUv3 device ID mapping index is used for SMMUv3 MSIs, update the IORT to support that. Signed-off-by: Hanjun Guo --- include/acpi/actbl2.h | 1 + 1 file changed, 1 insertion(+) -- 1.7.12.4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index 686b6f8..d90277e 100644 --- a/include/acpi/actbl2.h +++ b/include/acpi/actbl2.h @@ -810,6 +810,7 @@ struct acpi_iort_smmu_v3 { u8 pxm; u8 reserved1; u16 reserved2; + u32 id_mapping_index; }; /* Values for Model field above */ From patchwork Thu Sep 21 13:17:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 113256 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp2024814qgf; Thu, 21 Sep 2017 06:25:59 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAqw1IAt0WuaXy78jW5d2WSEAHYeAPaRE9EcSTF6uL1MyDTl1PIrkbVhgfjzqQ6nW5J8Nj2 X-Received: by 10.98.202.74 with SMTP id n71mr5674082pfg.139.1506000359154; Thu, 21 Sep 2017 06:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506000359; cv=none; d=google.com; s=arc-20160816; b=BWXmbcGCMRdZDDpSS/D8A6XBMC38OJlU5ZWGKxr5+5i21v5AMk2kGdSmC0al4kZuii EYZZoth48RJZRwsTiBwzyXNlM8RCwrWNdmhgJ5Kuu2dpwrUXOwNYovUVMps2Gq7/6yjB rQ9ZlKPrOlZ5u1YpJWgRbhGyWnrDe3VEzGU55sw136IegzAOrB6MMxCWWIiDezRh7yr/ AAa5RM0Eom5cmQHOc9DDtXPl/parnMlr2doQSid4Ox2EFa3hz42PoXAZXFoKOBrMwTtS xk1TfHd5Jtn0DLzXQfkR2BrSUuVcKsJD4H9JVgp34IXq+/fvdpHNxhqa9dGEu2pcrZf9 JnEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=cTwuv2AfFJpKSwNXOKNtCX+PAKQiAQvzs3ClZJPTKzo=; b=jq84/kk86Dny8p6dOU/8gSE7J8u9UQjFAU8uBr5+bRg6BRr3+STcSUdpJC7x+Ay9JV eqJRpQ/Sv2KnyuNzrdF/2RPp1saHgKhOz9A8zh3U36BZVdV/KEr4KD3wK2GQOuYx/tXI JjBx7tRJT79n01QS3C2RucnHaw407qanYLs2rXXpLq+6xgwsJBmS8dbzzTUeld1X9Vfl 0aNUuGttJTmFR4YQHaBa1t0HfEJ5+rIZLYRu3KhkVrkhsHDJlgUw772I4Aeub1nOC48e 0k/S320MDKkqa2/lFZ9gk3fqEbw58IOaLIBLsDguy0P0rJSs3oVA2jkm/3IGi1iyKwOX cCmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r6si1085604pls.393.2017.09.21.06.25.58; Thu, 21 Sep 2017 06:25:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751598AbdIUNZ6 (ORCPT + 7 others); Thu, 21 Sep 2017 09:25:58 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6963 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbdIUNZ5 (ORCPT ); Thu, 21 Sep 2017 09:25:57 -0400 Received: from 172.30.72.60 (EHLO DGGEMS407-HUB.china.huawei.com) ([172.30.72.60]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DHR58228; Thu, 21 Sep 2017 21:25:26 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.301.0; Thu, 21 Sep 2017 21:25:19 +0800 From: Hanjun Guo To: Lorenzo Pieralisi , Robin Murphy CC: Marc Zyngier , "Rafael J. Wysocki" , , , , Hanjun Guo Subject: [RFC PATCH v2 2/4] ACPI: IORT: lookup iort node via fwnode Date: Thu, 21 Sep 2017 21:17:16 +0800 Message-ID: <1505999838-52530-3-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 In-Reply-To: <1505999838-52530-1-git-send-email-guohanjun@huawei.com> References: <1505999838-52530-1-git-send-email-guohanjun@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59C3BDC6.01DD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 11ce73b1d75abe47b86518c719e1d56c Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org From: Hanjun Guo Now we have a helper function iort_get_fwnode() which lookup fwnode via iort node for SMMU, but sometimes we just need something exctly the opposite, which means we need to get the iort node via fwnode. For example, we need to get SMMU's iort node when adding support for SMMU MSI, but SMMU is not a named component which has a associated device node in DSDT, that means we can't match the ACPI full path name to get the iort node for SMMU. But with SMMU or other devices in IORT probed as platform device, it created a fwnode to associate with the iort node, so we introduce iort_get_iort_node() to get the iort node via fwnode. This can be extended to PMCG node usage in IORT too. Signed-off-by: Hanjun Guo --- drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) -- 1.7.12.4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 9565d57..db71d7f 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -126,6 +126,31 @@ static inline void iort_delete_fwnode(struct acpi_iort_node *node) spin_unlock(&iort_fwnode_lock); } +/** + * iort_get_iort_node() - Retrieve iort_node associated with an fwnode + * + * @fwnode: fwnode associated with device to be looked-up + * + * Returns: iort_node pointer on success, NULL on failure + */ +static inline +struct acpi_iort_node *iort_get_iort_node(struct fwnode_handle *fwnode) +{ + struct iort_fwnode *curr; + struct acpi_iort_node *iort_node = NULL; + + spin_lock(&iort_fwnode_lock); + list_for_each_entry(curr, &iort_fwnode_list, list) { + if (curr->fwnode == fwnode) { + iort_node = curr->iort_node; + break; + } + } + spin_unlock(&iort_fwnode_lock); + + return iort_node; +} + typedef acpi_status (*iort_find_node_callback) (struct acpi_iort_node *node, void *context); @@ -424,9 +449,25 @@ static struct acpi_iort_node *iort_find_dev_node(struct device *dev) { struct pci_bus *pbus; - if (!dev_is_pci(dev)) + if (!dev_is_pci(dev)) { + struct acpi_iort_node *node; + /* + * scan iort_fwnode_list to see if it's an iort platform + * device (such as SMMU, PMCG),its iort node already cached + * and associated with fwnode when iort platform devices + * were initialized. + */ + node = iort_get_iort_node(dev->fwnode); + if (node) + return node; + + /* + * if not, then it should be a platform device defined in + * DSDT/SSDT (with Named Component node in IORT) + */ return iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT, iort_match_node_callback, dev); + } /* Find a PCI root bus */ pbus = to_pci_dev(dev)->bus; From patchwork Thu Sep 21 13:17:17 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 113258 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp2024854qgf; Thu, 21 Sep 2017 06:26:01 -0700 (PDT) X-Google-Smtp-Source: AOwi7QD6f/PQn1ysamtZFUNs+rTG+NlXhJmQJi10YjVr9ewpXmSsHZrDOUpNXjhZ76fqn4NUWEDS X-Received: by 10.84.240.196 with SMTP id l4mr5475999plt.261.1506000361065; Thu, 21 Sep 2017 06:26:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506000361; cv=none; d=google.com; s=arc-20160816; b=NjyUEgyLEZBCgUR/m1ZzeLS2GVHjmPne5rL1xXOnR7uJBQ96cuuWCQ1P1kcRDJqMH5 JqxRZPoj08DGt/f1h2F1HyGml6PFELzmHQBOMdBDeoRbQ8yIIj/TWx98nJzXvaTJf8U2 T0lhlYs1Ok7DPPBq/4tkVsUreZVOhIkiGw25AJ35A8tko8zWBE86Vs49vflyjG2vfxm0 UIRsapl89r6MAHgrNClSlLKTJbjkZFiN6zTUIp/jzSQRWtfPFOWkWulmwtPmEsWOlqVq ub4pzIAoFZY6rEblbzJCrf8aRDH+YRU/ea9kFH3pIQNYAszROBa2lZpDQzF76zBDbPcj 9d9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=K2HxLh1/ItcTxafJw9sO29qtVUf3LCvjV2q8hfL8RAo=; b=Nd1D33EYH7EUg/FbkLUyhyhKaoO17tQfTpS9/GOekEvHJEKrcoQZGhVCIWAHDr0UCM dKN39M/JBOwmdNr0IY+bGVDpmA7Vw4aA39NXgNFYxk5NAuDcwFB+3Y+0DQ1kTpBrDebv XfohUVyH3tWnc5kS5Eb7lIJeqUmZgtdfR+zLQGLRXbbBJCl4Fn7ZXJ3fmJHZtwPMva42 UG9ohVfSnneBoU5uAI4trACAzgj5XVooBvqjkFzRC3up9AUCu7qWAHaas5LzwIkUKcPp OeQSU4od6HXrXm4wE9h8QjAqK4csj1R6plPzTbgtzcF9fp8RmI9Dw3w+LAs7m7YHZrgm 8J8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r6si1085604pls.393.2017.09.21.06.26.00; Thu, 21 Sep 2017 06:26:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751581AbdIUN0A (ORCPT + 7 others); Thu, 21 Sep 2017 09:26:00 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6965 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbdIUNZ7 (ORCPT ); Thu, 21 Sep 2017 09:25:59 -0400 Received: from 172.30.72.60 (EHLO DGGEMS407-HUB.china.huawei.com) ([172.30.72.60]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DHR58234; Thu, 21 Sep 2017 21:25:26 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.301.0; Thu, 21 Sep 2017 21:25:19 +0800 From: Hanjun Guo To: Lorenzo Pieralisi , Robin Murphy CC: Marc Zyngier , "Rafael J. Wysocki" , , , , Hanjun Guo Subject: [RFC PATCH v2 3/4] ACPI: IORT: Skip SMMUv3 device ID map for two steps mappings Date: Thu, 21 Sep 2017 21:17:17 +0800 Message-ID: <1505999838-52530-4-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 In-Reply-To: <1505999838-52530-1-git-send-email-guohanjun@huawei.com> References: <1505999838-52530-1-git-send-email-guohanjun@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59C3BDC6.0187, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 32d914643514d3c74084a04d0ea44cd5 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org From: Hanjun Guo IORT revision C introduced SMMUv3 MSI support which adding a device ID mapping index in SMMUv3 sub table, to get the SMMUv3 device ID mapping for the output ID (dev ID for ITS) and the link to which ITS. So if a platform supports SMMUv3 MSI for control interrupt, there will be a additional single map entry under SMMU, this will not introduce any difference for devices just use one step map to get its output ID and parent (ITS or SMMU), such as PCI/NC/PMCG ---> ITS or PCI/NC ---> SMMU, but we need to do the special handling for two steps map case such as PCI/NC--->SMMUv3--->ITS. Take a PCI hostbridge for example, |----------------------| | Root Complex Node | |----------------------| | map entry[x] | |----------------------| | id value | | output_reference | |---|------------------| | | |----------------------| |-->| SMMUv3 | |----------------------| | SMMU dev ID | | mapping index 0 | |----------------------| | map entry[0] | |----------------------| | id value | | output_reference-----------> ITS 1 (SMMU MSI domain) |----------------------| | map entry[1] | |----------------------| | id value | | output_reference-----------> ITS 2 (PCI MSI domain) |----------------------| When the SMMU dev ID mapping index is 0, there is entry[0] to map to a ITS, we need to skip that map entry for PCI or NC (named component), or we may get the wrong ITS parent. For now we have two APIs for ID mapping, iort_node_map_id() and iort_node_map_platform_id(), and iort_node_map_id() is used for optional two steps mapping, so we just need to skip the map entry in iort_node_map_id() for non-SMMUv3 devices. Signed-off-by: Hanjun Guo --- drivers/acpi/arm64/iort.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) -- 1.7.12.4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index db71d7f..269959e 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -366,6 +366,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node, return NULL; } +static int iort_get_smmu_v3_id_mapping_index(struct acpi_iort_node *node, + u32 *index) +{ + struct acpi_iort_smmu_v3 *smmu; + + /* + * SMMUv3 dev ID mapping index was introdueced in revision 1 + * table, not avaible in revision 0 + */ + if (node->revision < 1) + return -EINVAL; + + smmu = (struct acpi_iort_smmu_v3 *)node->node_data; + /* if any of the gsi for control interrupts is not 0, ignore the MSI */ + if (smmu->event_gsiv || smmu->pri_gsiv || smmu->gerr_gsiv + || smmu->sync_gsiv) + return -EINVAL; + + if (smmu->id_mapping_index >= node->mapping_count) { + pr_err(FW_BUG "[node %p type %d] ID mapping index overflows valid mappings\n", + node, node->type); + return -EINVAL; + } + + *index = smmu->id_mapping_index; + return 0; +} + static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, u32 id_in, u32 *id_out, u8 type_mask) @@ -375,7 +403,9 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, /* Parse the ID mapping tree to find specified node type */ while (node) { struct acpi_iort_id_mapping *map; - int i; + int i, ret = -EINVAL; + /* big enough for an invalid id index in practical */ + u32 index = U32_MAX; if (IORT_TYPE_MASK(node->type) & type_mask) { if (id_out) @@ -396,8 +426,19 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node, goto fail_map; } + /* + * we need to get SMMUv3 dev ID mapping index and skip its + * associated ID map for single mapping cases. + */ + if (node->type == ACPI_IORT_NODE_SMMU_V3) + ret = iort_get_smmu_v3_id_mapping_index(node, &index); + /* Do the ID translation */ for (i = 0; i < node->mapping_count; i++, map++) { + /* if it's a SMMUv3 device id mapping index, skip it */ + if (!ret && i == index) + continue; + if (!iort_id_map(map, node->type, id, &id)) break; }