Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp531369ybx; Wed, 6 Nov 2019 22:18:57 -0800 (PST) X-Google-Smtp-Source: APXvYqyKzZaWjdoushKtRJS2T47xoBSUZ+tWou3JohTBNCHnF507GGXvShQNuwYAJ1zY1CT48SNn X-Received: by 2002:aa7:cdc6:: with SMTP id h6mr1720425edw.15.1573107537085; Wed, 06 Nov 2019 22:18:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573107537; cv=none; d=google.com; s=arc-20160816; b=Rf3GOE5YPT42I1gxtlyP9o9/Grv+3+t0w3iq2sfeX1cc8clfuJDB8mNAIVvW1p3stu O2o17RA0kR5Qxa+5Smgc/GQc50ysS9QQLk/JwXHiq+D0EuJ1w/uZSNpzzgKAcQidl0aX vispxBOne1l+LtoPULQ6G7FSAPwiuHnmpI95y+GX+QY1UrgaIKzlH1mhu/jIJyqZynL4 Ga1YDNa44x6mbCBAlgmpSu3bKLL3+QDZIxroMVKRTK94Zf8QS6rlYdRpF1hJR1WBr82I Hui7RE0Wmck3kdSlUEh94IE0EGqldhNz1Vw3GWsZsS6LTpQfoh6t/BjD6WnSoVB6EY6u j52Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0adq3VsWHIu/rncfodFFEkNMnfieV/vfE3F2paMIBL8=; b=qoyySC86jb+bg6CM3JiunFNxg4Z5JtpgHUExNdOGlsCiKLsSzH8n5zsfoEtNABayA9 kMuw6HXjYjfVIHnQ7BGjUGX9mAA7KDrnEAOk1Yh3JMX2zxH5nj60PwqMx8x7ifyAHkS7 rSivrK6fl7fYb24pRENeskmlcDk6KZulQVrrk7rx8rqTFJhMzZXAs5ENdWMm0+RL19oY f8qeQCMkdCdG+rbjjRpJsKBuVqeXoqCz7N8uffq5F696bwPyjnlGCNgUqsDCKsSEtNmt hF+R185oFOWWqHLOfJJEnJb/fLygKeHCpCRXYKNB+w6z/27L6BZlxUy8+z8a07Mkoj0p BMsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=fT+bnEt+; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oz10si731404ejb.163.2019.11.06.22.18.33; Wed, 06 Nov 2019 22:18:57 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=fT+bnEt+; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726651AbfKGGRS (ORCPT + 99 others); Thu, 7 Nov 2019 01:17:18 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:34967 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725938AbfKGGRR (ORCPT ); Thu, 7 Nov 2019 01:17:17 -0500 Received: by mail-ot1-f68.google.com with SMTP id z6so1062186otb.2 for ; Wed, 06 Nov 2019 22:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0adq3VsWHIu/rncfodFFEkNMnfieV/vfE3F2paMIBL8=; b=fT+bnEt+40WN2y423AvRis/djiprLbX9Fj4L0pz8YCFpInBk6OhHJODAseWN0+lRNI gLPom3wNE27xYHIL4GPNr33clKTlZ2xiCfuGZNQjm8qKG8oZhrDfdexhTCYbnMkgwJye +ewgwtLNAVeStD4500bqVJM8HGwQjZ2nzHZa2lrotFN7ECMYzXDjTqpLgFoRCx02saYU TLZXWMkaLmIoQnjE/OkgO+xur4LupGcp0bpRGYgk6Fgn86ChH7nNNZ4rtTlx18b+K9we ZVFLsX/Y6ju+ljNnIyf0sdS81lFxqJEE7c9kgih+VxqoNd9aCrZBLQvpttUiSVIBUQq2 mgnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0adq3VsWHIu/rncfodFFEkNMnfieV/vfE3F2paMIBL8=; b=pHDLZ7VnPEeKdRhc3+2I4PXwOYAuxNKGuIeu66NeDGWLiaNCAKGMci401QtUdrRVhT ZmJ/IP341FNtJQDPIwQg4paQ8ok/0amwPsuntXy1YsN19N04prZKs1m1Wl25gbx/UtGT pZyWxsIQKJpO58g16slaWHBBQYB/oE1d73ri1KD+pJOg0vfmoaDGQSzTcSLlj1cQytIh NNxfKU6us/gHnOheZCvgtXuFFmBsn8yxjKSkRqln4o4/AA2//O7B0eb2cQYps3uu2nve EBb5SsxGBKvQIo1L6bWhe8/K8tKmR9nW+LgWZi1reJ2gcy/tycEi04wgQ8KpRyb80B2p 2mdg== X-Gm-Message-State: APjAAAXvSb3Qe6qe2tNQEMz4ecsUXG+YUY2UZKfeXHoxPNfHD1x9MhAs GvCeBl6o/iWLqUBN1mzO/xbB0LbcPVVJOg/p3gctvw== X-Received: by 2002:a9d:7ac2:: with SMTP id m2mr1443221otn.225.1573107436285; Wed, 06 Nov 2019 22:17:16 -0800 (PST) MIME-Version: 1.0 References: <20191030145112.19738-1-will@kernel.org> <6e457227-ca06-2998-4ffa-a58ab171ce32@arm.com> <20191030155444.GC19096@willie-the-truck> In-Reply-To: From: Saravana Kannan Date: Wed, 6 Nov 2019 22:16:40 -0800 Message-ID: Subject: Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers To: Will Deacon Cc: Robin Murphy , iommu@lists.linux-foundation.org, LKML , Joerg Roedel , Bjorn Helgaas , Lorenzo Pieralisi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 30, 2019 at 5:57 PM Saravana Kannan wrote: > > On Wed, Oct 30, 2019 at 8:54 AM Will Deacon wrote: > > > > Hi Robin, > > > > On Wed, Oct 30, 2019 at 03:35:55PM +0000, Robin Murphy wrote: > > > On 30/10/2019 14:51, Will Deacon wrote: > > > > As part of the work to enable a "Generic Kernel Image" across multiple > > > > Android devices, there is a need to seperate shared, core kernel code > > > > from modular driver code that may not be needed by all SoCs. This means > > > > building IOMMU drivers as modules. > > > > > > > > It turns out that most of the groundwork has already been done to enable > > > > the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig; > > > > with a few symbols exported from the IOMMU/PCI core, everything builds > > > > nicely out of the box. The one exception is support for the legacy SMMU > > > > DT binding, which is not in widespread use and has never worked with > > > > modules, so we can simply remove that when building as a module rather > > > > than try to paper over it with even more hacks. > > > > > > > > Obviously you need to be careful about using IOMMU drivers as modules, > > > > since late loading of the driver for an IOMMU serving active DMA masters > > > > is going to end badly in many cases. On Android, we're using device links > > > > to ensure that the IOMMU probes first. > > > > > > Out of curiosity, which device links are those? Clearly not the RPM links > > > created by the IOMMU drivers themselves... Is this some special Android > > > magic, or is there actually a chance of replacing all the > > > of_iommu_configure() machinery with something more generic? > > > > I'll admit that I haven't used them personally yet, but I'm referring to > > this series from Saravana [CC'd]: > > > > https://lore.kernel.org/linux-acpi/20190904211126.47518-1-saravanak@google.com/ > > > > which is currently sitting in linux-next now that we're upstreaming the > > "special Android magic" ;) > > Hi Robin, > > Actually, none of this is special Android magic. Will is talking about > the of_devlink feature that's been merged into driver-core-next. > > A one line summary of of_devlink: the driver core + firmware (DT in > this case) automatically add the device links during device addition > based on the firmware properties of each device. The link that Will > gave has more details. > > Wrt IOMMUs, the only missing piece in upstream is a trivial change > that does something like this in drivers/of/property.c > > +static struct device_node *parse_iommus(struct device_node *np, > + const char *prop_name, int index) > +{ > + return parse_prop_cells(np, prop_name, index, "iommus", > + "#iommu-cells"); > +} > > static const struct supplier_bindings of_supplier_bindings[] = { > { .parse_prop = parse_clocks, }, > { .parse_prop = parse_interconnects, }, > { .parse_prop = parse_regulators, }, > + { .parse_prop = parse_iommus, }, > {}, > }; > > I plan to upstream this pretty soon, but I have other patches in > flight that touch the same file and I'm waiting for those to get > accepted. I also want to clean up the code a bit to reduce some > repetition before I add support for more bindings. As promised: https://lore.kernel.org/lkml/20191105065000.50407-1-saravanak@google.com/ -Saravana