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

[Ben Warren]

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 at jcrosoft.com> you wrote:
>>>>         
>>>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at 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