From patchwork Mon May 22 10:37:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Pieralisi X-Patchwork-Id: 9739895 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 87F986034C for ; Mon, 22 May 2017 10:36:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7FA1E286DE for ; Mon, 22 May 2017 10:36:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 741EF286EF; Mon, 22 May 2017 10:36:33 +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 1ED62286DE for ; Mon, 22 May 2017 10:36:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757422AbdEVKgb (ORCPT ); Mon, 22 May 2017 06:36:31 -0400 Received: from foss.arm.com ([217.140.101.70]:34606 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757326AbdEVKga (ORCPT ); Mon, 22 May 2017 06:36:30 -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 62DC51435; Mon, 22 May 2017 03:36:29 -0700 (PDT) Received: from red-moon (red-moon.cambridge.arm.com [10.1.206.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0A4BD3F23B; Mon, 22 May 2017 03:36:24 -0700 (PDT) Date: Mon, 22 May 2017 11:37:31 +0100 From: Lorenzo Pieralisi To: Sricharan R Cc: robin.murphy@arm.com, will.deacon@arm.com, joro@8bytes.org, iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, m.szyprowski@samsung.com, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, tn@semihalf.com, hanjun.guo@linaro.org, okaya@codeaurora.org, robh+dt@kernel.org, frowand.list@gmail.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, rjw@rjwysocki.net, lenb@kernel.org, catalin.marinas@arm.com, arnd@arndb.de, linux-arch@vger.kernel.org, laurent.pinchart@ideasonboard.com, j.neuschaefer@gmx.net, geert@linux-m68k.org, magnus.damm@gmail.com Subject: Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER Message-ID: <20170522103730.GB7553@red-moon> References: <1495119257-26724-1-git-send-email-sricharan@codeaurora.org> <1495119257-26724-3-git-send-email-sricharan@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1495119257-26724-3-git-send-email-sricharan@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Hi Sricharan, On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: > While deferring the probe of IOMMU masters, xlate and > add_device callbacks called from iort_iommu_configure > can pass back error values like -ENODEV, which means > the IOMMU cannot be connected with that master for real > reasons. Before the IOMMU probe deferral, all such errors > were ignored. Now all those errors are propagated back, > killing the master's probe for such errors. Instead ignore > all the errors except EPROBE_DEFER, which is the only one > of concern and let the master work without IOMMU, thus > restoring the old behavior. > > Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error") > Signed-off-by: Sricharan R > --- > [V4] Added this patch newly. > > drivers/acpi/arm64/iort.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index c5fecf9..16e101f 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -782,6 +782,12 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev) > if (err) > ops = ERR_PTR(err); > > + /* Ignore all other errors apart from EPROBE_DEFER */ > + if (IS_ERR(ops) && (PTR_ERR(ops) != -EPROBE_DEFER)) { > + dev_dbg(dev, "Adding to IOMMU failed: %ld\n", PTR_ERR(ops)); > + ops = NULL; > + } > + > return ops; > } > It is getting a bit convoluted. Is not it better to propagate the error back and let acpi_dma_configure() make a decision accordingly ? Something like: -- >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/acpi/scan.c b/drivers/acpi/scan.c index e39ec7b..3a10d757 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -1371,8 +1371,8 @@ int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr) iort_set_dma_mask(dev); iommu = iort_iommu_configure(dev); - if (IS_ERR(iommu)) - return PTR_ERR(iommu); + if (IS_ERR(iommu) && PTR_ERR(iommu) == -EPROBE_DEFER) + return -EPROBE_DEFER; size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1); /*