Received: by 10.223.164.202 with SMTP id h10csp5417070wrb; Tue, 21 Nov 2017 09:22:26 -0800 (PST) X-Google-Smtp-Source: AGs4zMZFLxuWR8UggCiKO5Jpy+OIsOWSG06qSD09VqMN5DWd7zC7Y3PZv5p04xCivTef0lBF4J8l X-Received: by 10.84.218.204 with SMTP id g12mr18254068plm.213.1511284946010; Tue, 21 Nov 2017 09:22:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511284945; cv=none; d=google.com; s=arc-20160816; b=VCTTZr8Sgg4v3mj5T4mjvm11jpMiVCFEObSUkCmrBWbWwHnXKNG6bPY/5dkiRv6BkE mzHf+2XUkXRie5xCJKBB5Dr7B0UbLUF5v0ETWO/cUCTGdmvKGP4jFgFp+opHKDFbk7L2 e3jlWCaZdD9oeiiux+BdKdM6fpo1Kw+JH2LHplR6IE77EpnH8drS+eyqklodLv8IBwsT ic7xMRYph270CrcGyChvoRHRGFlM6Zj3eEeF45okEOfat5QewH43ZT+BHe55rcGFzQ4l TU4EsThCmEDd2dMNVWh2t4xUMF8E3Zr2lleu+HxYkZuPoQXhkjAwirIfxnONUtv3p2eK 54ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=sKxppaTUcFl/0WGVcMo8BJ9rdOkIIMsRzd8RyWYKc7g=; b=oYUKdYZnu9yMeGzna6Lb3FX4Tu9uMbiMkzavWi6N46FOosUc4x99NNmMrCjpzQHrCN iMTsyyNUVE8kL3XFfdb3pJ30go6UFk39vPGlIbXq52gPk6Q4ZGHmCjebK32LRe5uep5O WDYPl0dbI3X7hDhffxCP2oSbqB+Q9WLPQOpynzaISDnvMiie9yiWENzUVKW+K5VinOKz iaWU5aVwuSvas4IphTVLyYnlZV/6hV0CdHwsGGw4ssdq4UFkIPoWgh6H7a4xRdprpDqF o8Wcxn5NwFpJwNeGPT1uXCKhl2Fk9Rt9P55h7Fce3Cv+Gj9GJyQ40a30uP/VzEi1Kn2+ WYHQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u16si7176916pfl.380.2017.11.21.09.22.14; Tue, 21 Nov 2017 09:22:25 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751358AbdKURVg (ORCPT + 75 others); Tue, 21 Nov 2017 12:21:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54622 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbdKURVf (ORCPT ); Tue, 21 Nov 2017 12:21:35 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8FF2D85363; Tue, 21 Nov 2017 17:21:34 +0000 (UTC) Received: from t450s.home (ovpn-116-16.phx2.redhat.com [10.3.116.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id EDCC817F3C; Tue, 21 Nov 2017 17:21:32 +0000 (UTC) Date: Tue, 21 Nov 2017 10:21:32 -0700 From: Alex Williamson To: Liviu Dudau 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: <20171121102132.5d111f85@t450s.home> In-Reply-To: <20171121120801.GK5165@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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 21 Nov 2017 17:21:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, 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 "); > > > > > > > > > > > > > > > From 1584680645441820641@xxx Tue Nov 21 13:00:31 +0000 2017 X-GM-THRID: 1578902883289057090 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread