Hi Mike,
On 3/31/2010 12:59 PM, Mike Frysinger wrote: > On Wednesday 31 March 2010 10:46:25 Detlev Zundel wrote: > >> I fully agree. Previously I was under the impression that we already >> have a "fast initialization" (probe) and a "full initialization" (init) >> of the network interfaces, where programming the mac would (on a first >> stab) fit into the probe part (and some drivers obviously do/did this). >> >> In the meantime it seems like it is a broader problem of keeping >> "ethaddr" and friends in sync with the real hardware. Although this is >> something I personally always took for granted, it currently is most of >> the time but not always correct. >> >> If we solve the latter problem in a nice way, the initial problem will >> simply disappear (or so I hope) ;) >> > the latter problem is already solved in the general case. the first > initialize path gets the hw mac address and gives it to the common layers. > common layers take care of keeping the structures in sync. when the slow init > path gets called to actually bring up the hardware, the mac has already been > synced to the structures. correctly written devices never have to care about > anything other than dev->enetaddr and should not be programming the MAC with > the MAC address in the fast initialize path. > > really what you want is a new eth entry point like eth_write_mac() that goes > through the common layers and programs the MAC with the MAC address. this > isnt a problem with the current net framework. > Detlev and I were just talking off-list about exactly that. I guess 'great minds think alike', as my grandma used to say. > -mike > regards, Ben _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot