Thread (1 message) 1 message, 1 author, 2016-06-14

[PATCH v2 1/7] iommu/of: Respect disabled IOMMUs

From: robin.murphy@arm.com (Robin Murphy)
Date: 2016-06-14 15:04:22
Also in: linux-devicetree, linux-iommu

On 14/06/16 15:11, Will Deacon wrote:
On Fri, Jun 03, 2016 at 06:15:36PM +0100, Robin Murphy wrote:
quoted
If an IOMMU node is present in the DT but marked as disabled, we should
avoid trying to do anything with it. We currently sort-of get away with
this by virtue of a disabled device probably not having called
of_iommu_set_ops(), but that is hardly safe to rely upon in general, and
either way we don't want to treat it as an error condition with the
resulting "Failed to initialise IOMMU" message.
What's the use-case for this? I ask because epapr says that the device
binding should provide details as to exactly what "disabled" means for
that device.
Right now, it's mostly a case of making things behave as expected - the 
OF platform code is already assigning the implicit meaning of "don't 
probe or do anything with this device", so playing along with that 
prevents slightly confusing errors or potential null-dereference-style 
crashes as above.

Longer term, I was also thinking back to the probe ordering problem, and 
the sticky case of differentiating "this IOMMU isn't probed yet" from 
"this IOMMU will never probe, continue without it". Being able to make 
that decision from the bootloader (by disabling nodes) in at least a 
subset of cases seemed like a useful tool. I'm still open to other 
points of view, though.

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