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

[Simon Glass]

Hi Michael,

On Fri, 11 Dec 2020 at 01:55, Michael Walle <michael at walle.cc> wrote:
>
> Hi Simon,
>
> Am 2020-12-11 02:31, 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 assign sequence numbers to their devices, so that as soon as a
> > device is bound, it has a sequence number. If the uclass flag
> > DM_UC_FLAG_SEQ_ALIAS is enabled (as well as the CONFIG option), a
> > devicetree alias provides the number. Otherwise, the next available
> > number
> > (after the last alias and avoiding existing devices) is used.
> >
> > 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.
> >
> > This series is available at u-boot-dm/seq-working
> >
> > Changes in v2:
> > - Give all devices a sequence number
> > - Drop uclass_alloc_all_seqs() and GD_FLG_DM_NO_SEQ flag
> > - Drop the GD_FLG_DM_NO_SEQ flag
> > - Use the sequence number directly instead of max bus
> > - Adjust the tests to handle the new allocation scheme
> > - Drop the networking changes which are no-longer needed
> > - Update for new logic
> > - Adjust commit message
> > - Drop pointless check for max == -1
> > - Adjust the tests to handle the new allocation scheme
> > - Simplify the logic so auto_seq is positive
> > - Update the docs to indicate all devices get a sequence number
> > - Update the docs to explain how aliases reserve sequence numbers
> > - Drop commit changing efi_uc_destroy()
>
> Sequence numbers looks good, but PCI still doesnt work on my board.

Thanks for trying this out.

I suppose you have a different problem from what I found in v1. Can
you please send the output of these things before and after the
change?

dm tree
dm uc
pci
pci 1
(e.g. for other buses)
pci 0 long

Which board is it? I suppose there is a chance I have one.

Thanks,
Simon