Thread (45 messages) 45 messages, 7 authors, 2016-11-29

[PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

From: robin.murphy@arm.com (Robin Murphy)
Date: 2016-11-14 12:00:58
Also in: linux-acpi, linux-iommu, linux-pci, lkml

On 14/11/16 10:26, Lorenzo Pieralisi wrote:
Hi Robin, Joerg,

On Fri, Nov 11, 2016 at 05:43:39PM +0000, Robin Murphy wrote:
quoted
On 11/11/16 16:27, Joerg Roedel wrote:
quoted
On Fri, Nov 11, 2016 at 04:17:37PM +0000, Robin Murphy wrote:
quoted
In the original of_iommu_configure design, the thought was that an ops
structure could be IOMMU-instance-specific (hence the later-removed
"priv" member), so I suppose right now it is mostly a hangover from
that. However, it's also what we initialise a device's fwspec with, so
becomes important again if we're ever going to get past the limitations
of buses-which-are-not-actually-buses[1].
Yeah, I discussed this with a few others at LPC. My current idea is to
tell the iommu-core which hardware-iommus exist in the system and a
seperate iommu_ops ptr for each of them. Then every struct device can
link to the iommu-instance it is translated by.
Er, that sounds very much like a description of what we already have in
4.9-rc. Every struct device now has an iommu_fwspec which encapsulates
both an iommu_ops pointer (which can perfectly well be per-instance if
the IOMMU driver wants) and a place for the IOMMU-private data to
replace the mess of archdata.iommu and driver-internal globals.
quoted
We are not there yet, but this will give you the same per-device
iommu-ops as implemented here.
With those two patches I linked to, which make the bulk of the IOMMU
core code per-device-ops-aware off the bat, I'd say we *are* already
pretty much there. It's only iommu_domain_alloc() which needs a
device-based alternative, and the non-of_xlate-based IOMMU drivers to
either call iommu_fwspec_init() for themselves, or perhaps for x86
plumbing in DMAR/IVRS equivalents of the IORT parsing to the
infrastructure provided by this series.
I think it all boils down to how we end up implementing the per-device
iommu_ops look-up/binding, question is what do you want me to do with
this patch, it should be fine to drop it and use dev->bus->iommu_ops
for the look-up but I should know sooner rather than later to make
sure the series get another good round of testing.
If we've already made the decision to move away from bus ops, I don't
see that it makes sense to deliberately introduce new dependencies on
them. Besides, as it stands, this patch literally implements "tell the
iommu-core which hardware-iommus exist in the system and a seperate
iommu_ops ptr for each of them" straight off.

Robin.
Please let me know, thank you very much.

Lorenzo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help