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

[Simon Glass]

Hi Heinrich,

On Tue, 1 Dec 2020 at 01:32, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 11/30/20 2:53 AM, Simon Glass wrote:
> > 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.
> > For ad-hoc calls to device_bind() afterwards (e.g. from driver code), the
> > sequence is set to the maximum sequence number for the uclass + 1.
> >
> > Apart from the simplicity gains, overall these changes seem to reduce the
> > number of tweaks and workarounds needed to get the desired behaviour.
> >
> > However there will certainly be some problems created, so board
> > maintainers should test this out.
>
> What is the effect of the series on removable devices like USB storage,
> USB Ethernet, SATA disks, ...?

They should work as now, in that they get the maximum seq + 1.

>
> Is there a test for removable devices?

The test I added in this series covers the case of devices being bound
ad-hoc, so yes I think so.

Regards,
Simon