Hi Heinrich, On Tue, 1 Dec 2020 at 01:32, Heinrich Schuchardt <xypron.g...@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