From patchwork Thu Jul 20 14:31:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robin Murphy X-Patchwork-Id: 9855097 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A6CD0601C8 for ; Thu, 20 Jul 2017 14:31:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 96A8B287A7 for ; Thu, 20 Jul 2017 14:31:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8B883287AB; Thu, 20 Jul 2017 14:31:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E7399287A7 for ; Thu, 20 Jul 2017 14:31:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934437AbdGTObo (ORCPT ); Thu, 20 Jul 2017 10:31:44 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54882 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934428AbdGTObn (ORCPT ); Thu, 20 Jul 2017 10:31:43 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1695580D; Thu, 20 Jul 2017 07:31:43 -0700 (PDT) Received: from [10.1.210.24] (e110467-lin.cambridge.arm.com [10.1.210.24]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A12C93F483; Thu, 20 Jul 2017 07:31:40 -0700 (PDT) Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801 To: Shameerali Kolothum Thodi , Will Deacon Cc: "lorenzo.pieralisi@arm.com" , "marc.zyngier@arm.com" , "sudeep.holla@arm.com" , "hanjun.guo@linaro.org" , Gabriele Paoloni , John Garry , Linuxarm , "linux-acpi@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "Wangzhou (B)" , "Guohanjun (Hanjun Guo)" , "linux-arm-kernel@lists.infradead.org" , "devel@acpica.org" References: <20170623145801.325244-1-shameerali.kolothum.thodi@huawei.com> <20170623145801.325244-3-shameerali.kolothum.thodi@huawei.com> <20170704173820.GO22175@arm.com> <5FC3163CFD30C246ABAA99954A238FA83839DB59@FRAEML521-MBX.china.huawei.com> <20170714193322.GH26488@arm.com> <5FC3163CFD30C246ABAA99954A238FA8383B9D5A@FRAEML521-MBX.china.huawei.com> From: Robin Murphy Message-ID: Date: Thu, 20 Jul 2017 15:31:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8383B9D5A@FRAEML521-MBX.china.huawei.com> Content-Language: en-GB Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 19/07/17 11:48, Shameerali Kolothum Thodi wrote: > > >> -----Original Message----- >> From: Will Deacon [mailto:will.deacon@arm.com] >> Sent: Friday, July 14, 2017 8:33 PM >> To: Shameerali Kolothum Thodi >> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com; >> sudeep.holla@arm.com; robin.murphy@arm.com; hanjun.guo@linaro.org; >> Gabriele Paoloni; John Garry; Linuxarm; linux-acpi@vger.kernel.org; >> iommu@lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo); >> linux-arm-kernel@lists.infradead.org; devel@acpica.org >> Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based >> HiSilicon erratum 161010801 >> > [...] >>>>> - list_add_tail(®ion->list, head); >>>>> + if ((smmu->options & ARM_SMMU_OPT_RESV_HW_MSI)) { >>>>> + >>>>> + if (!is_of_node(smmu->dev->fwnode)) >>>>> + resv = iort_iommu_its_get_resv_regions(dev, head); >>>> >>>> How does this work when we're not using ACPI? Shouldn't of vs ACPI >>>> be abstracted from the driver? >>> >>> At present ARM_SMMU_OPT_RESV_HW_MSI is only set for ACPI and DT >>> support for this is a low priority for us at the moment. Is the >>> suggestion is to have a common function outside the smmu driver for >>> _iommu_its_get_resv_regions() ? I am not sure what is the best way here. >> >> Right, something like that. The driver shouldn't need to care whether or not >> it's using ACPI or DT when setting these options. > > Below is what I have in mind for the common function for msi reserve. > But just wondering invoking iort_ functions from iommu code > is acceptable or not . Could you please take a look and let me know. At that point, it seems like we might as well just roll it into iommu_dma_get_resv_regions() directly[1]. It probably makes sense for any DT equivalent to be described generically, rather than SMMU-specific, so parsing that would fit into common code as well. Then in the SMMU drivers we can skip creating the SW_MSI region if iommu-dma gave us back any real ones (and remove the apparently unnecessary resv_msi check in VFIO). Or be lazy and just leave it, as it doesn't seem to do much harm to have both. Robin. [1] This is what I hacked up locally on top of patch #1: ----->8----- --- 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/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 9d1cebe7f6cb..50292827da49 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -19,6 +19,7 @@ * along with this program. If not, see . */ +#include #include #include #include @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list) struct pci_host_bridge *bridge; struct resource_entry *window; + if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) && + iort_iommu_its_get_resv_regions(dev, list) < 0) + return; + if (!dev_is_pci(dev)) return;