On Thu, Feb 12, 2015 at 11:14 PM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 10 February 2015 at 23:08, Joe Hershberger joe.hershberger@gmail.com
wrote:
Hi Simon,
On Tue, Feb 10, 2015 at 10:39 PM, Simon Glass sjg@chromium.org wrote:
Hi Joe,
On 10 February 2015 at 18:30, Joe Hershberger joe.hershberger@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.
Not sure why you say that. The reason I need the seq number is because I need to look up the proper env variable for the MAC address. E.g. ethaddr, eth2addr, etc. The seq number select which one to read from the env.
I can think of some poor ways to do this but a nice way is not obvious!
Not sure what you're referring to here. What is "this" in this context?
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.
I had it probing the devices originally (by calling first and next) and you commented that it shouldn't happen until the devices are used. However, I don't think we can guarantee that all drivers that come later will have simple probe (since that's not part of the contract). I think I agree with your original statement that we should not probe. It seems more suitable to write the hwaddr in bind as a known and limited side effect.
The seq number resolution seems fairly well contained as I implemented it in bind. I simply call the core function and write the result to the device member. Then of course this patch to remove the assert.
Thanks, -Joe