[U-Boot] [RFC PATCH v3 01/14] dm: core: Allow seq numbers to be resolved before probe

[Simon Glass]

Hi Joe,

On 10 February 2015 at 23:08, Joe Hershberger <joe.hershberger at gmail.com> wrote:
> Hi Simon,
>
> On Tue, Feb 10, 2015 at 10:39 PM, Simon Glass <sjg at chromium.org> wrote:
>>
>> Hi Joe,
>>
>> On 10 February 2015 at 18:30, Joe Hershberger <joe.hershberger at ni.com>
>> wrote:
>> > Before this patch, if the sequence numbers were resolved before probe,
>> > this code would insist on defining new non-conflicting-with-itself seq
>> > numbers. Now any "non -1" seq number is accepted as already resolved.
>>
>> Can you explain what problem this solves? At present, when probing a
>> device, ->seq must be -1 (sort-of by definition since it doesn't exist
>> as an active device in the uclass).
>
> Please look at eth_post_bind() in patch 07/14.  The Ethernet devices need to
> write their hardware addresses to the registers in bind (since it needs to
> happen regardless of the device being used so that Linux will see the MAC
> address).  As such, the sequence number is needed to look up the ethaddr. In
> order to avoid probing all the devices to get the seq number resolved, I
> resolve it in post_bind to avoid the rest of the overhead (thus no longer
> probing in post_bind, which was one of the issues previously).  Then when
> probe comes along, the seq is already resolved.  That's why this patch is
> needed.

OK I see.

This is a bit messy. If the MAC address assignment is part of the bind
step then it shouldn't need the seq number.

I can think of some poor ways to do this but a nice way is not obvious!

One option would be probe all the Ethernet devices on startup. If
probe() only set up the hardware (including MAC address) then that
might work. It would be fairly fast since it wouldn't involve starting
up the link, etc. I suspect you are worried about a lot of Ethernet
devices sitting around probed by unused. I'm not sure if that matters
though.

Regards,
Simon