linux-kernel - Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140618092906.GA32699@arm.com>
Date:	Wed, 18 Jun 2014 10:29:06 +0100
From:	Will Deacon <will.deacon@....com>
To:	Stuart Yoder <stuart.yoder@...escale.com>
Cc:	Varun Sethi <Varun.Sethi@...escale.com>,
	Mark Rutland <Mark.Rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
	Pawel Moll <Pawel.Moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Grant Grundler <grundler@...omium.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Linux IOMMU <iommu@...ts.linux-foundation.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Cho KyongHo <pullip.cho@...sung.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

On Tue, Jun 17, 2014 at 03:50:25PM +0100, Stuart Yoder wrote:
> > > I think for simple masters (i.e. those that have all their StreamIDs
> > > under control of one driver), then setting something during attach (or
> > > add?) based on the DT could work pretty well. The other case is when we
> > > have masters behind a bridge (such as a PCI RC). In this case, it might
> > > actually be better to ask the bridge for the IDs and let it sort out
> > the
> > > allocation itself. That would also move the RequesterID -> StreamID
> > > mapping out of the SMMU code.
> > >
> > > What do you think?
> > The PCI bus iommu group creation code would be part of the SMMU driver
> > (it is handled by other IOMMU drivers as well). My understanding is that
> > there would be one is to one correspondence between the requestor ID and
> > the iommu group. May be, we can have an API provided by the PCI bridge
> > (architecture specific) for setting the stream ID.
> 
> I think Will is suggesting something along those lines-- I think it's a
> question of where the streamID allocation happens.  You could
> either do something like the following in the SMMU driver when attaching
> a PCI device:
> 
>     id = alloc_stream_id(...);
>     pci_set_streamid(pci-dev, id);
> 
>     or
> 
>     id = pci_get_streamid(pci-dev);
> 
> ...i.e the PCI RC could allocate (from some TBD
> allocator) and set the stream ID itself.
> 
> Not sure how big a deal it is to extend PCI RC interfaces for 
> something like that.

I think both interfaces have their place; the latter for hotpluggable buses
and the former for static allocation (i.e. set once). The only way to see
how well it works is to try implementing it, I guess.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/