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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 25 Jun 2014 10:18:59 +0100
From:	Will Deacon <will.deacon@....com>
To:	Olav Haugan <ohaugan@...eaurora.org>
Cc:	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>,
	Joerg Roedel <joro@...tes.org>,
	Stephen Warren <swarren@...dotorg.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	Linux IOMMU <iommu@...ts.linux-foundation.org>,
	Rob Herring <robh+dt@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Cho KyongHo <pullip.cho@...sung.com>,
	Dave P Martin <Dave.Martin@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Hiroshi Doyu <hdoyu@...dia.com>
Subject: Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

On Tue, Jun 24, 2014 at 10:35:54PM +0100, Olav Haugan wrote:
> On 6/24/2014 11:11 AM, Will Deacon wrote:
> > On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> >> On 6/24/2014 2:18 AM, Will Deacon wrote:
> >>> On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> >>>> We have multiple-master SMMUs and each master emits a variable number of
> >>>> StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
> >>>> for this) to the StreamIDs due to limited number of StreamID 2 Context
> >>>> Bank entries in the SMMU. If my understanding is correct we would
> >>>> represent this in the DT like this:
> >>>>
> >>>> 	iommu {
> >>>> 		#address-cells = <2>;
> >>>> 		#size-cells = <0>;
> >>>> 	};
> >>>>
> >>>> 	master@a {
> >>>> 		...
> >>>> 		iommus = <&iommu StreamID0 MASK0>,
> >>>> 			 <&iommu StreamID1 MASK1>,
> >>>> 			 <&iommu StreamID2 MASK2>;
> >>>> 	};
> >>>
> >>> Stupid question, but why not simply describe the masked IDs? What use does
> >>> the `raw' ID have to Linux?
> >>
> >> We do describe the masked StreamID (SID) but we need to specify the mask
> >> that the SMMU should apply to the incoming SIDs, right?
> >>
> >> We have a bus master that emits 43 unique SIDs. However, we have only 40
> >> SMMU_SMRn registers in the SMMU. So we need to mask out some of the
> >> incoming SID bits so that the 43 SIDs can match one of 40 entries in the
> >> SMR.
> > 
> > Hmm, so you're talking about stream matching, right? That doesn't belong in
> > the device-tree. I appreciate that the current driver does a terrible job at
> > allocating the SMRs (it's bloody difficult!), but we should try to improve
> > the dynamic behaviour instead of moving configuration of the SMMU out into
> > device-tree, where it's inflexible at best.
> 
> I am talking about SMMU_SMRn[MASK] register bits. This is not something
> that can be dynamically detected at run-time. It is configuration at the
> same level as the actual StreamIDs.

Why can't it be dynamically detected? Whilst the StreamIDs are fixed in
hardware (from the SMMU architecture perspective), the SMRs are completely
programmable. Why doesn't something like Andreas's proposal work for you?
The idea there was to find the constant bits among the StreamIDs for a
master and create the mask accordingly.

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/