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

Michael Walle michael at walle.cc
Fri Dec 11 09:55:32 CET 2020


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.

-michael


More information about the U-Boot mailing list