On Fri, Oct 25, 2013 at 11:49:05AM +0200, Hiroshi Doyu wrote: > Thierry Reding <thierry.reding@xxxxxxxxx> 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. Thierry
Attachment:
pgpFsaB1e9Qxc.pgp
Description: PGP signature
