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.
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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
