Re: [PATCHv3 01/19] [HACK] of: dev_node has struct device pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

> 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?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux