From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Wed, 12 Aug 2009 16:16:46 -0700 Subject: [U-Boot] [PATCH 1/3] net/eth_device: keep index inside each device In-Reply-To: <20090812212651.GA11003@game.jcrosoft.org> References: <1250023747-20224-1-git-send-email-plagnioj@jcrosoft.com> <20090812185054.63898833DBD2@gemini.denx.de> <20090812210339.GE21725@game.jcrosoft.org> <4A833107.1010209@gmail.com> <20090812212651.GA11003@game.jcrosoft.org> Message-ID: <4A834D5E.4000406@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>> --- >>>>> 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