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

Ben Warren
2009-08-12T23:16:46Z

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