Subject: How to handle named resources with DT?

From: [email-masked] (Cousson, Benoit)
Date: Tue, 9 Aug 2011 23:44:35 +0200

On 8/9/2011 11:17 PM, Grant Likely wrote:
> On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 10:57 PM, Grant Likely wrote:
>>> On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
>>>> On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
>>>>> On 8/9/2011 7:23 PM, Grant Likely wrote:
>>>>>> 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.
>>>>> For the same IP, the number of entries can vary depending of the SoC
>>>>> revision.
>>>>> By using the _byname, we can check if the resource is there or not
>>>>> without having to care about the position.
>>>>
>>>> You could have a named u32 property that contains the reg index, e.g.:
>>>>
>>>> dev {
>>>> 	reg =<0x20000 0x200 0x24000 0x200>;
>>>> 	foo-reg =<0>;
>>>> 	bar-reg =<1>;
>>>> };
>>>
>>> That's a little nasty.  A reg-names = "foo", "bar"; would probably be
>>> better.
>>
>> Yep, I agree.
>>
>> And what about something like that?
>>    reg =<0x20000 0x200>, "foo",
>> 	<0x20000 0x200>, "bar" ;
>>
>> It is doable?
>
> Definitely not.  It would break all existing 'reg' parsing
> implementations quite badly.

OK, so what about extending the reg attribute to be a reg node?

dev {
	reg {
		name = "foo_wrapper";
		start = <0x10000>;
		end = <0x200>;
	}
	reg {
		name = "foo";
		start = <0x20000>;
		end = <0x200>;
	}
}

A little bit more verbose, but at least we can add any attribute we want.

Regards,
Benoit