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

[Simon Glass]

Hi Jon,

On 9 July 2014 07:53, Jon Loeliger <loeliger at gmail.com> wrote:
> 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.

If we don't add numbering to driver model, then it will be done badly
(and ad-hoc) in support code. I can't even quite imagine how we might
do it. Also while U-Boot's numbering may not be the right long-term
approach, that would involve a large discussion and long change-over
to an as-yet unknown method. So I think we need to have realistic
expectations of driver mode's place in the world. It can enable new
methods, but not mandate them.

>
>> 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.

There's nothing in this patch that precludes that. It would require
changes to U-Boot's command processing, probably best done as a
separate series sometime in the future.

>
>> 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?

If you compare with how things are now, we only support a single
driver for each class. For example, if you are using SPI, you can only
have one SPI driver - perhaps with multiple ports. If you are not
using DT, then the U_BOOT_DEVICE() macros will all appear in that
driver or the board file (TBD at this stage), and will be parsed in
order. I believe we can honour the numbering in that case, albeit I
don't want to implement something before it is needed.

>
>
>> +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.

I think you are saying that something like:

sf probe spi1:flash

should be possible instead of

sf probe 1:0

It feels right to me too, but it doesn't belong in this patch, needs
further discussion and the command parsing aspect needs more general
thought. It would be great to figure this out and get it agreed, and
driver model can certainly support it.

Regards,
Simon