Jean-Christophe PLAGNIOL-VILLARD wrote:
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-plagnioj@jcrosoft.com you wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagnioj@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
I find it convenient to get a driver handle via eth_get_dev_by_name() and then access its elements (MAC address etc.) through the handle. Not exactly the most efficient way, but it's certainly convenient. This is how I modified all the eeprom-accessing standalone apps with SMC911X and SMC91111 (which, BTW, your SMC91111 patch didn't fix) to work with CONFIG_NET_MULTI.
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
Not a good direction to take if possible.
this one is generic
Best Regards, J.
Ben