On Fri, Aug 26, 2011 at 04:13:15PM +0200, Cousson, Benoit wrote:

On 8/26/2011 12:58 PM, Arnd Bergmann wrote:

quoted

On Friday 26 August 2011, David Gibson wrote:

quoted

Seriously, how many times do I have to say it?

[...]

quoted

quoted

Insisting that the names come from the DT is to mistakenly think of
the DT as an extension of the kernel's internal interfaces, instead of
as the external and OS neutral data structure it actually is.

You are wrongly interpreting the consequence: a smart Linux guy
added a _byname API, without seeing the real cause: most HW
resources have a name to identify them and not a number.

No, I'm really not.

quoted

Agreed, that was my main point anyway: Getting the name from the
device tree would be a huge mistake.

No, it would not. In fact, storing name in DT is even much more
aligned with the goal of DT for my point of view, since it is
supposed to describe the HW without any assumption about the OS
usage. DT data are supposed to be driven by the HW specs.

So, I actually agree that in the long term getting resource names in
the DT would be a generally good thing.

But doing so is a *huge* change in one of the very core semantics of
all the DT bindings.  It's not something that should be done lightly
or quickly.  It absolutely should not be tied to how this is handled
on the Linux side.  Therefore *for now* it is much better to have glue
which binds existing DT practice to the new Linux interface; then
thinking about this from the DT point of view can be a long term
project.

The ordering you are relying on for the moment is purely arbitrary
and do not have any signification for the HW point of view. Just
have a look at a HW spec and you will see that most signals have a
*name*, not a number, to identify them.

Sure, but assigning that arbitrary order is well-established practice
for device DT bindings.

Without that, you have to add some unnecessary and error prone
processing to the original information:
- Encode an information that is there originally (resource name from
the HW spec) into a arbitrary number without any meaning: Why tx_irq
should be before the rx_irq and after the err_irq???
- Remove the original name to confuse people.
- Expect the driver to use a number that does not come from the HW
spec but from a DT binding text file to figure out what resource it
has to use.

No, I don't expect that bit - see the discussion of how we can glue
the DT order to names inside the kernel.

- Pray that the driver guy didn't wrongly interpret the irq #2138469
to be the tx_irq instead of the rx_irq.

Um, this is an order, not an arbitrary int number.  So try irq #2.
Maybe #3 or #4 on a really complicated device.

If you extend a little bit the scope of the discussion and start
considering that clocks, voltage rails, reset lines are as well a
resources for the IP point of view, do you really think that using a
number to identify a clock or a voltage will really make sense?
Guess what? The current clock binding is using clock name...

Yes.  There's a big difference between creating a new binding to use
names, and creating a new practice in the core DT semantics used by
every single existing binding.

In order to have a consistent way of using resources in DT, it makes
sense to have the ability to provide a name for any kind of
resources.
BTW, adding a name should not prevent people to use the legacy by
index method.


Moreover, anybody deserve to have a name... Otherwise we will end up
with situation like that:

resource #6: Who are you?
resource #2: The new #2.
resource #6: Who is #1?
resource #2: You are #6.
resource #6: I am not a number, I am a free resource.

Allusions to TV programs do not an argument make, no matter how
interesting and influential they might have been.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson