Message ID | 20201217042034.411902-1-sjg@chromium.org |
---|---|
Headers | show |
Series | dm: Change the way sequence numbers are implemented | expand |
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 <michael@walle.cc> [on kontron_sl28] -michael