On Fri, 25 Oct 2013 12:49:38 +0200, Thierry Reding <thierry.red...@gmail.com> wrote: > On Fri, Oct 25, 2013 at 11:49:05AM +0200, Hiroshi Doyu wrote: > > Thierry Reding <thierry.red...@gmail.com> wrote @ Fri, 25 Oct 2013 11:11:05 > > +0200: > > > > > > > This is actually "the other problem that I'm aware of that could > > > > > benefit > > > > > from [interrupt resolution at probe time]". My idea was that once we > > > > > had > > > > > a way within the driver core to resolve interrupt references at probe > > > > > time it could be used for potentially many other resources as well. > > > > > Some > > > > > of the resources like GPIOs and regulators are obviously not something > > > > > that the core can or should be requesting, but mostly resources that > > > > > you > > > > > don't actually need to control after probing (such as interrupts) > > > > > would > > > > > be a good fit because otherwise people would write the same > > > > > boilerplate > > > > > over and over again. > > > > > > > > > > IOMMUs seem to me to be in that same category. As far as I can tell, > > > > > an > > > > > IOMMU driver registers the IOMMU for a given bus, upon which every > > > > > device can simply be used (mostly transparently) with that IOMMU. > > > > > While > > > > > I haven't figured out how exactly, I'm pretty sure we can take > > > > > advantage > > > > > of the resolution of resources at probe time within the core to both > > > > > keep drivers from having to do anything in particular and at the same > > > > > time have code to determine if the IOMMU driver hasn't been probed yet > > > > > and return -EPROBE_DEFER appropriately. > > > > > > > > Can you explain the above a bit more? > > > > > > > > Originally I thought that what Grant suggested would work ok with this > > > > patch. > > > > > > I think the objection to these patches is that they special case the > > > instantiation of some devices. It's not a proper solution because it > > > implies various things. For example merely instantiating the IOMMU > > > device earlier than others is only going to work *if* the driver is > > > actually probed before the drivers of other devices. If you want to > > > build the driver as a module for example, probe order becomes entirely > > > non-deterministic. > > > > I understand the above limitation. What I thought for the solution is > > that I can make use of iommu_bus even before IOMMU is > > instanciated. iommu_bus has its notifier which calls > > iommu_ops()->add_device(). This could return -EPROBE_DEFER when IOMMU > > isn't ready. Only the problem is the current "bus_notifier" doesn't > > have the ability to return error. I'll see if it can be modified. Even > > with this, at least IOMMU *driver* needs to be init'ed enough earlier > > to prevent devices from being registered without IOMMU. > > The way notifiers work is that they run completely hidden from whatever > triggers them. For instance you register the IOMMU bus notifier from the > IOMMU driver (by calling bus_set_iommu()). That registers a function to > be called when some event happens on that bus. When a device's driver is > probed successfully, the driver core will notify the bus, which causes > the IOMMU callback to be run. > > Some of this code runs before the driver has successfully been probed, > so I imagine it would be possible to use it to abort probing. But that's > not possible at least with the current code. > > > > Instead of handling such dependencies implicitly by making sure all > > > resource providers are probed earlier than any of their consumers, the > > > dependencies are handled more explicitly, which turns out to simplify > > > things a lot. There's some additional work required in the core, but if > > > done consistently no driver needs to care about the dependencies and it > > > no longer matters where the resources come from. The problem is reduced > > > to essentially this: > > > > > > while (!resource_available()) > > > load_more_drivers(); > > > > > > So my proposed solution for the IOMMU case is to treat it the same as > > > any other resources. Perhaps resource isn't the right word, but at the > > > core the issue is the same. A device requires the services of an IOMMU > > > so that it can be put into the correct address space. If the IOMMU is > > > not available yet it cannot do that, so we simply return -EPROBE_DEFER > > > and cause the probe to be retried later. > > > > This looks somewhat similar to the above iommu_bus notifier. > > > > Is there any way to implement the same mechanism rather than using > > bus? > > Yes, I think it should be possible to get this to work without using the > bus notifier at all. I can try to code something up but wanted to wait > for feedback from Grant first.
I've lost track. What feedback are you waiting for from me? I've not dug into this entire series so I may not provide clueful feedback. g. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
