On 14:15 Wed 12 Aug , Ben Warren wrote: > Jean-Christophe PLAGNIOL-VILLARD wrote: > >On 20:50 Wed 12 Aug , Wolfgang Denk wrote: > >>Dear Jean-Christophe PLAGNIOL-VILLARD, > >> > >>In message <1250023747-20224-1-git-send-email-plagn...@jcrosoft.com> you > >>wrote: > >>>Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagn...@jcrosoft.com> > >>>--- > >>> include/net.h | 1 + > >>> net/eth.c | 17 +++++------------ > >>> 2 files changed, 6 insertions(+), 12 deletions(-) > >>What exactly is the problem you are addressing with this patch? > >> > >>Please provide a commit message that explains what is going on, and > >>what is being changed or fixed. > >simple it impossible to known what will be your device index in the driver > >specially when you have 2 or more drivers instance once or more > >so you can not update the mac addres in the env if you want to do it > >as we do on smc91111 as we can not known eth%daddr you are > >which allow us the avoid to read the eeprom every time we want to use the eth > > > While I'm not completely opposed to the idea of tracking indices, > it's simply not true that you don't know the indices of the > controllers on your board. They're all instantiated in > board_eth_init(), so the first will be 0 and the second will be 1 > etc. If you had a mix of devices and they were found by probing as > in Linux, it would be different. Here in U-boot, ordering is > deterministic and dictated by the developer. but you can not known it in the driver specially if you have multi different MAC chip 2 SMC91111 + 1 SOC MAC
and you will add it in the order of preferance to use for the board to let u-boot try to connect in the order of your preference as example this order SOC_M_0 SMC9111_0 SMC9111_1 so you can do this board_eth_init() { call cpu_eth_init register smc91111_0 register smc91111_1 } in an other board I can prefer board_eth_init() { call cpu_eth_init register smc91111_0 register smc91111_1 } so instead of duplicate the info and the code you just allow the driver to known is index > > BTW - this is hardly the first driver that can have multiple > instances. Others, such as TSEC, seem to be managing just fine. each drivers do his own way this one is generic Best Regards, J. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot