[PATCH 00/27] dm: Change the way sequence numbers are implemented

[Simon Glass]

Hi Tom,

On Wed, 9 Dec 2020 at 09:19, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Dec 08, 2020 at 11:52:07PM +0100, Michael Walle wrote:
> > Hi Simon,
> >
> > Am 2020-11-30 02:53, schrieb Simon Glass:
> > > At present each device has two sequence numbers, with 'req_seq' being
> > > set up at bind time and 'seq' at probe time. The idea is that devices
> > > can 'request' a sequence number and then the conflicts are resolved when
> > > the device is probed.
> > >
> > > This makes things complicated in a few cases, since we don't really know
> > > (at bind time) what the sequence number will end up being. We want to
> > > honour the bind-time requests if at all possible, but in fact the only
> > > source of these at present is the devicetree aliases.
> > >
> > > Apart from the obvious need for sequence numbers to supports U-Boot's
> > > numbering on devices on the command line, the current scheme was
> > > designed to:
> > >
> > > - avoid calculating the sequence number until it is needed, to save
> > >   execution time
> > > - allow multiple devices to obtain a particular sequence number as they
> > >   are probed and removed
> > > - retain a record of the 'requested' sequence number even if it turns
> > > out
> > >   that a device could not get it (to allow debugging and retrying)
> > >
> > > After some years using the current scheme it seems on balance that these
> > > goals don't have as much merit as first thought. The first point would
> > > be persuasive except that we end up reading the devicetree aliases at
> > > bind-time anyway. So the work of resolving the sequence numbers during
> > > probing is not that great. The second point hasn't really been an issue,
> > > as there is typically no contention for sequence numbers (boards tend to
> > > allocate them statically in the devicetree). Re the third point, we can
> > > often figure out what was requested by looking at aliases, and in the
> > > cases where we can't, it doesn't seem to matter much.
> > >
> > > Since we have the devicetree available at bind time, we may as well just
> > > use it, in the hope that the required processing will turn out to be
> > > useful later (i.e. the device actually gets used). In addition, it is
> > > simpler to use a single sequence number, since it avoids confusion and
> > > some extra code.
> > >
> > > This series moves U-Boot to use a single, bind-time sequence number. All
> > > uclasses with the DM_UC_FLAG_SEQ_ALIAS flag enabled will assign sequence
> > > numbers to their devices, so that as soon as a device is bound, it has a
> > > sequence number. If a devicetree alias provides the number, it will be
> > > used. Otherwise, during initial binding, the first free number is used.
> >
> > What does "first free number mean"?
> >
> > I have a device tree with the following aliases for network:
> >
> > aliases {
> >         ethernet0 = &enetc0;
> >         ethernet1 = &enetc1;
> >         ethernet2 = &enetc2;
> >         ethernet3 = &enetc6;
> > };
> >
> > The individual devices might be disabled, depending on the board variant
> > (which might also be dynamically determined during startup).
> >
> > My first smoke test with this series show the following:
> >
> >   uclass 32: eth
> >   0   * enetc-0 @ ffd40e60, seq 0
> >   1   * ax88179_eth @ ffd51f50, seq 1
> >
> > Looks like the usb ethernet device will get seq 1 assigned (after "usb
> > start"). Is this intended?
> >
> > If so, this is a problem, because for ethernet devices, the MAC address
> > is assigned according to the ethNaddr variable. And at least for this
> > board (kontron_sl28) the first four are reserved for the ones with the
> > alias entries. Thus I'd have expected that the usb device will get seq 4
> > assigned.
>
> I want to echo this concern.  One of the things that can be challenging
> when working with devices in Linux is that it's now long accepted that
> you can't rely on anything like probe order as that can and will change
> randomly (seemingly).  You have to instead rely on some stable attribute
> of the device.  Consistency of device numbering is a feature for us.

This is still using aliases for devices that have them. But for
dynamically allocated devices (without aliases) we always rely on what
is next available. I think I can change the algorithm to look for the
number after all existing aliases.

Regards,
Simon