From patchwork Wed May 3 10:24:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sricharan Ramabadhran X-Patchwork-Id: 9709151 X-Patchwork-Delegate: geert@linux-m68k.org 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 3B7336021C for ; Wed, 3 May 2017 10:25:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 22B3828469 for ; Wed, 3 May 2017 10:25:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 160F8285F9; Wed, 3 May 2017 10:25:14 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID 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 D882128469 for ; Wed, 3 May 2017 10:25:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbdECKZM (ORCPT ); Wed, 3 May 2017 06:25:12 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58918 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751491AbdECKZL (ORCPT ); Wed, 3 May 2017 06:25:11 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 3125460A00; Wed, 3 May 2017 10:25:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1493807110; bh=C6G0IjoCgXsazxK94cm+Nz6I5u56nCJxy9eHu11NkKA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=T4HgFQsHhyAyoEAChNU7KXDlRwz60m1UOZ49g0j8C96V65mNwEMXAJ2GZEjj+XGel XUZBxYMACz1rqpFXi/YgXzeIxXeLwA8kN/oJiR0dN7hpzCprQcap2TUAgG561JX4w6 vtkW39HgGbG8WgLzjMNHCgCOwv4ObP7aMc7s/moU= Received: from [10.201.3.39] (unknown [202.46.23.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sricharan@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 8064C60A00; Wed, 3 May 2017 10:25:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1493807107; bh=C6G0IjoCgXsazxK94cm+Nz6I5u56nCJxy9eHu11NkKA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ExxU3SIE2GakCfJ+y+LCCKZqHattVRY93KwbNrwVL4Zx6Muf39OY2/TFolgKzqC35 O3y7ZoY2B9g+ISvxhcOBEmNzceGcdlwmLDq5CRrbBJUcIWWD/qjZe5x/h7krYTHGN1 JQc97iiqcPmdREoK0bmA62D95pxKWMBR8BYZsyZE= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 8064C60A00 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sricharan@codeaurora.org Subject: Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error To: Robin Murphy , Geert Uytterhoeven Cc: Will Deacon , Joerg Roedel , Lorenzo Pieralisi , iommu@lists.linux-foundation.org, "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , Marek Szyprowski , Bjorn Helgaas , linux-pci , ACPI Devel Maling List , tn@semihalf.com, Hanjun Guo , okaya@codeaurora.org, Magnus Damm , Linux-Renesas References: <1486136933-20328-1-git-send-email-sricharan@codeaurora.org> <1486136933-20328-8-git-send-email-sricharan@codeaurora.org> <2bfd11dc-9f94-2b69-7b03-c640e53155e1@arm.com> From: Sricharan R Message-ID: <26defadf-6380-4af4-6323-b51198376bc1@codeaurora.org> Date: Wed, 3 May 2017 15:54:59 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <2bfd11dc-9f94-2b69-7b03-c640e53155e1@arm.com> Content-Language: en-US Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Robin, On 5/3/2017 3:24 PM, Robin Murphy wrote: > Hi Geert, > > On 02/05/17 19:35, Geert Uytterhoeven wrote: >> Hi Sricharan, >> >> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote: >>> From: Laurent Pinchart >>> >>> Failures to look up an IOMMU when parsing the DT iommus property need to >>> be handled separately from the .of_xlate() failures to support deferred >>> probing. >>> >>> The lack of a registered IOMMU can be caused by the lack of a driver for >>> the IOMMU, the IOMMU device probe not having been performed yet, having >>> been deferred, or having failed. >>> >>> The first case occurs when the device tree describes the bus master and >>> IOMMU topology correctly but no device driver exists for the IOMMU yet >>> or the device driver has not been compiled in. Return NULL, the caller >>> will configure the device without an IOMMU. >>> >>> The second and third cases are handled by deferring the probe of the bus >>> master device which will eventually get reprobed after the IOMMU. >>> >>> The last case is currently handled by deferring the probe of the bus >>> master device as well. A mechanism to either configure the bus master >>> device without an IOMMU or to fail the bus master device probe depending >>> on whether the IOMMU is optional or mandatory would be a good >>> enhancement. >>> >>> Tested-by: Marek Szyprowski >>> Signed-off-by: Laurent Pichart >>> Signed-off-by: Sricharan R >> >> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers. >> As the IOMMU nodes in DT are not yet enabled, all devices having iommus >> properties in DT now fail to probe. > > How exactly do they fail to probe? Per d7b0558230e4, if there are no ops > registered then they should merely defer until we reach the point of > giving up and ignoring the IOMMU. Is it just that you have no other > late-probing drivers or post-init module loads to kick the deferred > queue after that point? I did try to find a way to explicitly kick it > from a suitably late initcall, but there didn't seem to be any obvious > public interface - anyone have any suggestions? > > I think that's more of a general problem with the probe deferral > mechanism itself (I've seen the same thing happen with some of the > CoreSight stuff on Juno due to the number of inter-component > dependencies) rather than any specific fault of this series. > I was thinking of an additional check like below to avoid the situation ? From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001 From: Sricharan R Date: Wed, 3 May 2017 13:16:59 +0530 Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER While returning EPROBE_DEFER for iommu masters take in to account of iommu nodes that could be marked in DT as 'status=disabled', in which case simply return NULL and let the master's probe continue rather than deferring. Signed-off-by: Sricharan R Tested-by: Will Deacon Acked-by: Will Deacon --- drivers/iommu/of_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 9f44ee8..e6e9bec 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node *np) ops = iommu_ops_from_fwnode(fwnode); if ((ops && !ops->of_xlate) || + !of_device_is_available(iommu_spec->np) || (!ops && !of_iommu_driver_present(iommu_spec->np))) return NULL;