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. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
