quoted

quoted

quoted

What problem does any of this solve?  The device binding for the
"mcasp" device will have to describe the possible "reg-names", and
what those mean; but the binding already has to describe its "reg"
property anyway.

What this solve is the ability to use the
platform_get_resource_byname directly to retrieve the proper
register base address.

You do not have to put it in the device tree for that, the device
driver can implement this itself if it cares.

???

The driver is the user of that name, so it has to be populated  
before into the resource during device creation.

It can be as simple as

#define FOO_REG_INDEX 0
#define BAR_REG_INDEX 1

but you can use C strings if you want to.

quoted

quoted

The binding is just a text description that the driver will not be
able to use directly. It will have to get the resource using an
abstract index.

Your reg-names are abstract identifiers just as well.

This is the name used in the HW documentation.

So?  The device binding will still have to list them, for exact spelling
and register block size etc.

Ordering them to get a number is purely arbitrary.

Ordering them is required, "reg" is an array.  It also matters which
entry is the first entry (for the unit address).

That's why using the name will allow the driver to get the resource  
the way it is represented in the documentation and thus avoid some  
intermediate number.

You use an intermediate string instead, and add code and binding to
translate that to that same number.

quoted

quoted

It thus removes a level of indirection that is error prone and
useless most of the time.

It *adds* a level of indirection.  I doubt it helps prevent errors
either, but who knows.

Well, if that does not bring anything to you, you can just not use it.

I could, if you did this for your device binding only, but it seems
you are adding this as a generic thing.  I am very much against that.
The device tree should describe the hardware; it shouldn't describe
the description of the hardware, that's what bindings are for.


Segher