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

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

On 10/31/2013 02:14 AM, Hiroshi Doyu wrote:
> Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.