Thierry Reding <thierry.red...@gmail.com> wrote @ Wed, 30 Oct 2013 23:41:09
+0100:
> My earlier proposal for deferred interrupt reference resolution actually
> tries to solve that problem within the core. Essentially what it does is
> add a new function that gets called right before the driver's .probe()
> function, so that it can parse standard resources and services from DT,
> such as the interrupts property. This could theoretically be done for
> other resources such as reg as well, but it really only matters where
> the resource can be dynamic (as is the case for interrupts).
>
> In this case I would envision a standard OF function to associate a
> device with its IOMMU. Perhaps something like:
>
> int of_iommu_attach(struct device *dev);
>
> That could be called by the core independent of the specific device and
> IOMMU. IOMMU-specifics can probably be handled using .of_xlate(), quite
> in a similar way to GPIO or regulators.
>
> That way drivers can remain agnostic of the IOMMU while still being able
> to take advantage of deferred probing.
This could be simpler than making "bus_notifier" return "-EPROBE_DEFER".
The disadvantage of this is that we may need to provide the similar
of_<"subsystem">_attach() per subsytem if needed.
The version of "bus_notifier()" may be flexible since it just uses
the existing "bus_notifier()" framework although the return value
needs to be checked. This impact on the existing code isn't so small
unfortunately since NOTIFY_{DONE,OK,STOP,MASK,BAD} macros are used a
lot:(
I'll implement the version of "bus_notifier()" experimentally to see
how this looks like.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
