On Thu, Oct 31, 2013 at 10:37:40AM -0600, Stephen Warren wrote: > On 10/31/2013 02:14 AM, Hiroshi Doyu wrote: > > 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. > > Well, "per subsystem" here means per subsystem that is providing > resources, not per subsystem that is consuming resources. How many > subsystems are you expecting to provide resources like this? At present, > I believe IOMMU is the only subsystem missing some kind of API for > clients to acquire the relevant resource. I don't think there's any > scalability problem here.
Furthermore if the subsystem wants to provide resources then it needs such a function anyway, so there really isn't any overhead here. Thierry
pgpRfzgRtVHSL.pgp
Description: PGP signature
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
