Am 2020-12-17 05:20, 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.
Note that it is still possible to have the uclass manually allocate
sequence numbers, using the DM_UC_FLAG_NO_SEQ flag. This is used by
PCI,
due to its special requirements.
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 v3:
- Update PCI to use manual sequence numbering
- Add new patch to test DM_UC_FLAG_NO_AUTO_SEQ
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
- Drop special numbering in the i2c uclass
- Add new patch to allow manual sequence numbering
- 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()
Tested-by: Michael Walle <mich...@walle.cc> [on kontron_sl28]
-michael
