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

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2511 bytes --]

On Wed, Oct 30, 2013 at 03:58:58PM -0600, Stephen Warren wrote:
> On 10/25/2013 03:11 AM, Thierry Reding wrote:
> ...
> > 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.
> 
> Personally, I view deferred probe as being used when one device
> requires either a resource /or/ a service provided by another, not
> /just/ when there's a resource dependency. Hence, I think it fits
> perfectly here.
> 
> So I agree with Thierry: In other words, I think the solution is for
> all devices that are affected by an IOMMU to have a property such as:
> 
> iommu = <&iommu_phandle iommu_specifier>;
> 
> (and the DT node for the IOMMU will contain e.g. an #iommu-cells property)
> 
> ... and for the driver to explicitly parse that property, and wait
> until the driver for iommu_phandle is ready. Exactly the same as any
> other resource/service dependency.
> 
> That will solve all the problems.
> 
> The only downside is that every driver needs to contain code to parse
> that property. However, I think that's just one function call; the
> actual implementation of that function can be unified somewhere inside
> core code in drivers/iommu/.

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.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]