From patchwork Wed Aug 9 10:53:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 109713 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp706452qge; Wed, 9 Aug 2017 04:04:08 -0700 (PDT) X-Received: by 10.99.0.77 with SMTP id 74mr7271797pga.299.1502276648414; Wed, 09 Aug 2017 04:04:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502276648; cv=none; d=google.com; s=arc-20160816; b=SHKQpI7JCF/eKw+CqDCKy7Vas5tGquJSyuGX3kYOxFiUftJoS97adcjyYyJ1Cg2oVQ /3E8mN9oJH62Cj+nVNaH1Q3oPkn6mXv161FJDPa5sYieowftFPzCFjoF/Es8uyPSvtZG LYC4AhD8GsZsIv0taVPzASxZrwNCRsTtpl/HRg93brFpKq6JXeBPoVwhVsmcIaHjNQkk vtIRtsELNKb59UgjxYuMsAfy6/LSaPIwvjZJd8qZjwr+899ybXzgsuU371YUY5KGiY9F uCV41NfTWyK2JjVfdjmQhNUVaD8HNKuxofjtA/lgTH4MyJN4230hj5Wvj88S3WWPg/TC AEBg== 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=jgwRgg6dmiXfiK1BHvA4Zfqg53YTtLNxTiuWPtFoK3g=; b=HdJlseasgO/kD6/bSfUBejzqfVR+lMkiKE7492RYln4jvDoN08MzQyCALk9OqbvNIA GN1PXeOhr7EYG5hl0z4ZiYuZhjFKaCP9diGtfpgAj1dt3fpguvSz+yoggxwfqA2C/Mhc Q6ap5hQ0E69F0KcB5J3tQdNummeCNPmwrusB6tELsXaHae6UJ2zYoC4zRfyEWoYWxkVp 4Avzt6IPnolKxJSTdwFi+0ue8FaOZezV6/2HtVELNkGz/rLxQlLS2cJlcaAshxGUQ7M1 WCcBjUYefkBDk9Ckd36OiDCWtOeL+6MeQxC4lMEbgBfNjrVGUUmEQZ4DZy1W4FZnrgDE o8AQ== 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 x69si2401191pfj.283.2017.08.09.04.04.08; Wed, 09 Aug 2017 04:04:08 -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 S1752049AbdHILEH (ORCPT + 7 others); Wed, 9 Aug 2017 07:04:07 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:3481 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995AbdHILEH (ORCPT ); Wed, 9 Aug 2017 07:04:07 -0400 Received: from 172.30.72.59 (EHLO DGGEMS411-HUB.china.huawei.com) ([172.30.72.59]) by dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id DEU08678; Wed, 09 Aug 2017 19:00:42 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.301.0; Wed, 9 Aug 2017 19:00:33 +0800 From: Hanjun Guo To: Lorenzo Pieralisi CC: , , , Sinan Kaya , "Rafael J. Wysocki" , Marc Zyngier , Hanjun Guo Subject: [RFC PATCH 2/4] ACPI: IORT: lookup iort node via fwnode Date: Wed, 9 Aug 2017 18:53:35 +0800 Message-ID: <1502276017-63108-3-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 In-Reply-To: <1502276017-63108-1-git-send-email-guohanjun@huawei.com> References: <1502276017-63108-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.598AEB5A.02CE, 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: 76834548841793c0429aa72f18786820 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 fa99798..32bd4a4 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;