[U-Boot] [PATCH v2 17/29] dm: Introduce device sequence numbering

[Jon Loeliger]

HI Simon,

On Tue, Jul 8, 2014 at 10:38 PM, Simon Glass <sjg at chromium.org> wrote:
> In U-Boot it is pretty common to number devices from 0 and access them
> on the command line using this numbering. While it may come to pass that
> we will move away from this numbering, the possibility seems remote at
> present.
>
> Given that devices within a uclass will have an implied numbering, it
> makes sense to build this into driver model as a core feature. The cost
> is fairly small in terms of code and data space.

Hmmm.  I'm not entirely in agreement here.  I think this is the wrong
long-term approach, and this just reinforces the status quo rather than
allowing a migration to a better approach.

> With each uclass having numbered devices we can ask for SPI port 0 or
> serial port 1 and receive a single device.

That's nice, but we should allow them to be named by their actual
names as found in the device tree too.

> Devices typically request a sequence number using aliases in the device
> tree. These are resolved when the device is probed, to deal with conflicts.
> Sequence numbers need not be sequential and holes are permitted.

So they are unreliably unpredictable, unless you also happen
to have the DTS decoder ring in hand too?


> +This indicates that in the uclass called "serial", the named node
> +("/serial at 22230000") will be given sequence number 2. Any command or driver
> +which requests serial device 2 will obtain this device.
> +
> +Some devices represent buses where the devices on the bus are numbered or
> +addressed. For example, SPI typically numbers its slaves from 0, and I2C
> +uses a 7-bit address. In these cases the 'reg' property of the subnode is
> +used, for example:
> +
> +{
> +       aliases {
> +               spi2 = "/spi at 22300000";
> +       };
> +
> +       spi at 22300000 {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               spi-flash at 0 {
> +                       reg = <0>;
> +                       ...
> +               }
> +               eeprom at 1 {
> +                       reg = <1>;
> +               };
> +       };

And not everyone agrees that this is the best approach, even in Linux land.
Specifically, we should be in agreement with Linux, and we should not
have our DTS stray from the definitions that Linux will accept for the same
devices.  And this approach won't be bought by the Linux crowd.  (Yes,
there are some that use  a "reg = <0>;" approach here, but there are many
that do not too.  It's not a universally accepted approach.)

This concept is crucial.

I've said it before, and I will say it again if needed.

So:  Sure, put this approach in, but make it be the backward compatible
approach.  Also please put in a correct naming approach so that we can
move forward with a better longer term solution too.

Thanks,
jdl