On Aug 9, 2011, at 1:47 PM, Cousson, Benoit wrote:

> On 8/9/2011 7:23 PM, Grant Likely wrote:
>> On Tue, Aug 9, 2011 at 10:57 AM, Cousson, Benoit<b-cous...@ti.com>  wrote:
>>> Hi Manju,
>>> 
>>> On 8/9/2011 6:29 PM, G, Manjunath Kondaiah wrote:
>>>> 
>>>> Hi Benoit,
>>>> 
>>>> On Tue, Aug 09, 2011 at 11:23:20AM +0200, Cousson, Benoit wrote:
>>>>> 
>>>>> Hi Grant,
>>>>> 
>>>>> Trying to bind hwmod informations with DT, I'm facing a little
>>>>> limitation.
>>>>> A bunch of drivers are using the platform_get_resource_byname, so
>>>>> the name for the resource is needed.
>>>>> 
>>>>> The name is used so far for IORESOURCE_MEM, IORESOURCE_IRQ and
>>>>> IORESOURCE_DMA types of resources.
>>>> 
>>>> IORESOURCE_MEM and IORESOURCE_IRQ's are fetched from dt blob and
>>>> it will be part of pdev.
>>> 
>>> Yes, but without the proper name in the resource structure. It will be then
>>> impossible to use the platform_get_resource_byname function that is
>>> currently used by a bunch of drivers.
>> 
>> There is no analogous mechanism for _byname in the device tree.  The
>> DT binding for a device must explicitly state what order the register
>> ranges are in.  The driver will need to be adapted.
> 
> That seems to be a small regression for my point of view. Relying on the 
> order is not super safe. This is not very readable either. That's for that 
> exact reason that we changed our drivers to use platform_get_resource_byname. 
> That's probably the reason why that API is there as well.

That's exactly what the reasoning was for adding it.

http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-12/1944.html

-Matt

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to