How to handle named resources with DT?

[Cousson, Benoit]

On 8/10/2011 9:22 PM, Grant Likely wrote:
> On Tue, Aug 9, 2011 at 7:52 PM, David Gibson
> <david at gibson.dropbear.id.au>  wrote:
>> On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
>>> On 8/9/2011 11:49 PM, Grant Likely wrote:
>>>> 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.
>>
>> 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.
>
> I'm inclined the same way, though I agree with the replies that point
> out it wouldn't result in a 'flag day' because existing bindings
> cannot become incompatible.  The problem I have is that adding
> reg-names or similar implies that ordering of the reg property is no
> longer defined which I absolutely do not think is a good idea.

That will not be an issue if "reg-named" is a completely new node. It 
will replace the "reg" node only when a named entry is needed.
Most devices will use the regular "reg" entry, and only the one that 
need extra information will use the reg-named.

That seems to be pretty straightforward to implement, and as soon as it 
is useful even for a couple of drivers, it worth adding it.

It is anyway better than having to add a custom property to get the 
information we will miss otherwise.

Moreover, since some drivers are relying on that call, it will avoid 
having to add extra code for nothing if CONFIG_OF is set.

It will allow the driver to use a pretty standard API in anycase vs 
using platform_get_resource + some extra optional calls to of_ functions 
+ some code to get the information for non-DT build.

> Please, stick with the established convention and explicitly order
> 'reg' and 'interrupts' properties.  If there is a specific use case
> where this doesn't work, then bring it up, but I haven't seen any yet.

There will always be some alternatives, but they will be uglier, and the 
effort to add some extra node to DT is so small, that it is better to do 
that instead of adding some useless extra code in the driver.

>   The current users of _byname that I've looked seem to only use it for
> convenience, not because a register range may be optional.  ie. they
> all fail out if a reg resource isn't present.

If that API can help the driver writer and can avoid adding 10 lines of 
code, it is still useful to use it.

To be honest, I still do not understand why you are so reluctant to add 
that small feature.

That will not break compatibility and it will make our life easier.
Don't you want to make our life easier? :-)

Benoit