Received: by 10.223.164.202 with SMTP id h10csp5422675wrb; Tue, 21 Nov 2017 09:27:34 -0800 (PST) X-Google-Smtp-Source: AGs4zMZ/qak1z5JspWpfSofHNizgIDZymub34SsTDb45/1ow1qXUzycTs54z1gkzIO8xpAj9aJcw X-Received: by 10.101.67.140 with SMTP id m12mr17344344pgp.51.1511285254852; Tue, 21 Nov 2017 09:27:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511285254; cv=none; d=google.com; s=arc-20160816; b=uM9V5cj+m4e0szJ0bMWt5iv88tlxOGIYr5Z++yPhYyRzMpsj5mp+lL8KOEFApMuSEC G7FS+W7aXqc3Zq4WCw8w+3B5/g7GDJPzzJmQv+/BXomLUvherUlhdqXVN7tPF1OLkFb1 UIvgHEl6iujFVHtc0L+zcUfG9QZaDZOdhI5Px4Oz8jHSDfFfk7DPaCaAc8A5PCdLOEdL mcwkU6aESIbKalGd6MDBt6xoxpHkNssqipAJnbwmy4tpA+RBt1qu0YsVRpGhLDeHuEbT F2qst2mlZiGagPgJ3UXSnUtfWu6f9nRrdx6fdHTsLmwKIn9+/hKCpoRsFV5WaMbT4uQy kuZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=w7AoxGch4aHdrpn/2W2QCbl/iZsH9LlWUCsQOQ6XLLk=; b=KrFBBQQSZHYhPIbMo5w3Pl4ER/JZiT0MOEoTUy1gb3hvFbEz5Oe02owbnidR6dJELP I4d+l5ndsn1f30OfRRSu5BOYv+rks/Ux8VlqjbXiXznFrnThpdPf6Aco98PM3Oa2T+uD cwj5ob29F1xxfFbE6DPwq02G08hgKMkVKW5hOY+ZgEufBxhdESGsaHHJVUm0y0QjyoBg MztS+qUTG9gv4+ChM8Mhz3CF9BHEfvk7B7hZOuAnhEdYGeY+eYH4BvSwa7oSjy2x/R8z ZNn+dgfFFGSXIl+y+Ni+2BbNXtXxaf0eFPcUYaXiH9DQRssBdwzGw1JrTQl6EPHWJPFc Lrxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 65si10738786pgh.33.2017.11.21.09.27.22; Tue, 21 Nov 2017 09:27:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751306AbdKUR0n (ORCPT + 75 others); Tue, 21 Nov 2017 12:26:43 -0500 Received: from foss.arm.com ([217.140.101.70]:43286 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbdKUR0m (ORCPT ); Tue, 21 Nov 2017 12:26:42 -0500 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 446B080D; Tue, 21 Nov 2017 09:26:42 -0800 (PST) Received: from e110455-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E5EA13F487; Tue, 21 Nov 2017 09:26:41 -0800 (PST) Received: by e110455-lin.cambridge.arm.com (Postfix, from userid 1000) id 4AA5C680253; Tue, 21 Nov 2017 17:26:40 +0000 (GMT) Date: Tue, 21 Nov 2017 17:26:40 +0000 From: Liviu Dudau To: Alex Williamson Cc: Robin Murphy , Laurent Pinchart , Geert Uytterhoeven , Magnus Damm , LKML , IOMMU ML , Shawn Lin Subject: Re: [PATCH v2] iommu/ipmmu-vmsa: Do not replace bus IOMMU ops on driver init. Message-ID: <20171121172640.GC1119@e110455-lin.cambridge.arm.com> References: <20170918100444.21878-1-Liviu.Dudau@arm.com> <20170920141352.29377-1-Liviu.Dudau@arm.com> <938d213c-f207-218e-554f-08035eaa1e6d@arm.com> <20171120142514.GI5165@e110455-lin.cambridge.arm.com> <20171120150144.13390f70@t450s.home> <20171121120801.GK5165@e110455-lin.cambridge.arm.com> <20171121102132.5d111f85@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171121102132.5d111f85@t450s.home> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 21, 2017 at 10:21:32AM -0700, Alex Williamson wrote: > On Tue, 21 Nov 2017 12:08:01 +0000 > Liviu Dudau wrote: > > > On Mon, Nov 20, 2017 at 03:01:44PM -0700, Alex Williamson wrote: > > > On Mon, 20 Nov 2017 14:25:14 +0000 > > > Liviu Dudau wrote: > > > > > > > On Fri, Oct 13, 2017 at 04:48:45PM +0100, Robin Murphy wrote: > > > > > Hi Joerg, > > > > > > > > Hi, > > > > > > > > > > > > > > On 20/09/17 15:13, Liviu Dudau wrote: > > > > > > If the IPMMU driver is compiled in the kernel it will replace the > > > > > > platform bus IOMMU ops on running the ipmmu_init() function, regardless > > > > > > if there is any IPMMU hardware present or not. This screws up systems > > > > > > that just want to build a generic kernel that runs on multiple platforms > > > > > > and use a different IOMMU implementation. > > > > > > > > > > > > Move the bus_set_iommu() call at the end of the ipmmu_probe() function > > > > > > when we know that hardware is present. With current IOMMU framework it > > > > > > should be safe (at least for OF case). > > > > > > > > > > > > Now that the ipmmu_init() and ipmmu_exit() functions are simple calls to > > > > > > platform_driver_register() and platform_driver_unregister(), replace > > > > > > them with the module_platform_driver() macro call. > > > > > > > > > > Are you OK with taking this patch as a fix for 4.14, or would you rather > > > > > have something that can safely backport past 4.12 without implicit > > > > > dependencies? This is a config/link-order dependent thing that's been > > > > > lurking since the beginning, but only coming to light now that other > > > > > drivers are changing their behaviour, so I don't think there's really a > > > > > single Fixes: commit that can be singled out. > > > > > > > > Can someone update me on the fate of this patch? Can someone queue it > > > > for the next release? > > > > > > Sorry, this is another patch that wasn't on my radar while Joerg is out > > > on paternity leave. I didn't follow the replies to Laurent's question > > > about ordering and perhaps this plays in to Robin asking about fixes > > > for specific kernel versions. It seems there are some changes > > > elsewhere that somehow defer the ordering problem or don't matter on an > > > Arm Juno board (whatever that is). Can someone explain? > > > > Hi Alex, > > > > Thanks for replying! > > > > Laurent was positing that doing the bus_set_iommu() call in the probe > > function will break setups > > Yes, I understood that. Replying that it was on an Arm64 Juno board > did not in any way clarify to me how that concern is addressed. Thanks, Ah, sorry about that! The Juno board is only an example of where the problem can occur, but I think any arm64 board (because arm64 defines CONFIG_IOMMU_DMA) that runs a kernel compiled with multiple IOMMU drivers and includes the IPMMU without using it will suffer. Best regards, Liviu > > Alex > > > > If there's a > > > desire for a stable tag for this, it seems like we need to know > > > explicitly the range where it's safe to apply. Also, the patch needs > > > to be updated and re-evaluated in the presence of: > > > > > > cda52fcd999f iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE() > > > > > > Thanks, > > > Alex > > > > > > > > > Signed-off-by: Liviu Dudau > > > > > > Cc: Laurent Pinchart > > > > > > --- > > > > > > drivers/iommu/ipmmu-vmsa.c | 29 +++++------------------------ > > > > > > 1 file changed, 5 insertions(+), 24 deletions(-) > > > > > > > > > > > > diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c > > > > > > index 195d6e93ac718..31912997bffdf 100644 > > > > > > --- a/drivers/iommu/ipmmu-vmsa.c > > > > > > +++ b/drivers/iommu/ipmmu-vmsa.c > > > > > > @@ -966,10 +966,11 @@ static int ipmmu_probe(struct platform_device *pdev) > > > > > > return ret; > > > > > > > > > > > > /* > > > > > > - * We can't create the ARM mapping here as it requires the bus to have > > > > > > - * an IOMMU, which only happens when bus_set_iommu() is called in > > > > > > - * ipmmu_init() after the probe function returns. > > > > > > + * Now that we have validated the presence of the hardware, set > > > > > > + * the bus IOMMU ops to enable future domain and device setup. > > > > > > */ > > > > > > + if (!iommu_present(&platform_bus_type)) > > > > > > + bus_set_iommu(&platform_bus_type, &ipmmu_ops); > > > > > > > > > > > > platform_set_drvdata(pdev, mmu); > > > > > > > > > > > > @@ -1006,27 +1007,7 @@ static struct platform_driver ipmmu_driver = { > > > > > > .remove = ipmmu_remove, > > > > > > }; > > > > > > > > > > > > -static int __init ipmmu_init(void) > > > > > > -{ > > > > > > - int ret; > > > > > > - > > > > > > - ret = platform_driver_register(&ipmmu_driver); > > > > > > - if (ret < 0) > > > > > > - return ret; > > > > > > - > > > > > > - if (!iommu_present(&platform_bus_type)) > > > > > > - bus_set_iommu(&platform_bus_type, &ipmmu_ops); > > > > > > - > > > > > > - return 0; > > > > > > -} > > > > > > - > > > > > > -static void __exit ipmmu_exit(void) > > > > > > -{ > > > > > > - return platform_driver_unregister(&ipmmu_driver); > > > > > > -} > > > > > > - > > > > > > -subsys_initcall(ipmmu_init); > > > > > > -module_exit(ipmmu_exit); > > > > > > +module_platform_driver(ipmmu_driver); > > > > > > > > > > > > MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU"); > > > > > > MODULE_AUTHOR("Laurent Pinchart "); > > > > > > > > > > > > > > > > > > > > > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ From 1584697123884082076@xxx Tue Nov 21 17:22:26 +0000 2017 X-GM-THRID: 1578902883289057090 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread