How to handle named resources with DT?

Grant Likely grant.likely at secretlab.ca
Wed Aug 10 15:22:16 EDT 2011


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.

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.
 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.

So, the original answer stands, don't use _byname for DT bindings.

g.



More information about the linux-arm-kernel mailing list