How to handle named resources with DT?

[Cousson, Benoit]

On 8/10/2011 3:52 AM, David Gibson wrote:
> On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
>> On 8/9/2011 11:49 PM, Grant Likely wrote:
>>> On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
>>>> 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.
>>>
>>> That won't work either because that also breaks the existing 'reg'
>>> binding.  Anything you do will need to supplement the existing
>>> binding without changing it in an incompatible way.
>>
>> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
>> reg_named...?
>
> He already suggested reg-names to be interpreted in parallel with the
> existing reg property.  The (serious) problem with replacing the reg
> property is that it will break all existing OSes (including old Linux
> versions) that don't understand the new property.

That's why I was proposing a new extended node for that. Legacy tag will 
still be there for legacy HW.

Adding reg-names is doable easily, but not super nice. And the same 
trick will be needed for IRQs and then DMAs (not yet in core DT anyway).
Having a more scalable mechanism to allow further improvement will be good.

> Of course, the problem with reg-names is that it will be ignored by
> older OSes, and so 'reg' must still be in the correct order.  In which
> case you could argue it's more sensible to just have a static place to
> name mapping in the Linux driver.
>
> In short, yes, named reg elements in the DT would be nice in theory,
> but I'm not convinced it's worth a DT flag day to accomplish it.

Sorry, but I'm not sure to understand the meaning of that last sentence.

Benoit