How to handle named resources with DT?
Grant Likely
grant.likely at secretlab.ca
Thu Aug 11 05:22:16 EST 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 devicetree-discuss
mailing list