[U-Boot] [PATCH 1/3] net/eth_device: keep index inside each device

Jean-Christophe PLAGNIOL-VILLARD
2009-08-12T21:26:51Z

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
>
> 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.