[U-Boot] Pull request - net

[Ben Warren]

Wolfgang,

The following changes since commit bfc7bea6adc46e1db2f5a5e3464d7652ed67c864:
   Wolfgang Denk (1):
 Merge branch 'master' of git://git.denx.de/u-boot-x86

are available in the git repository at:

   git://git.denx.de/u-boot-net.git master

Andreas Bießmann (2):
   drivers/net/at91_emac.c: increase timeout for autonegotiation
   drivers/net/at91_emac.c: change return values

Ben Gardiner (1):
   davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr

Ben Warren (1):
   Net: Remove redundant CONFIG_NET_MULTI directives

Ilya Yanok (1):
   mpc5xxx_fec: add call to reset_phy() after PHY initialization

Joakim Tjernlund (4):
   net: Fix faulty definition of uec_initialize()
   UEC: Don't udelay needlessly
   UEC PHY: Remove strange 0.5 sec delay
   UEC PHY: Speed up initial PHY neg.

Michal Simek (2):
   net: Fix emaclite driver to support little-endian microblaze
   net: Move Emaclite to NET_MULTI

Peter Tyser (1):
   rarp: Condtionally compile rarp support

Reinhard Meyer (1):
   NET: add ENC28J60 driver using SPI framework

Reinhard Meyer (-VC) (1):
   NET: move legacy enc28j60.c to sidetrack as enc28j60_lpc2292.c

Thomas Chou (1):
   smc9: add write_hwaddr

  arch/arm/include/asm/arch-davinci/emac_defs.h |1 -
  arch/arm/lib/board.c  |   19 -
  board/davinci/common/misc.c   |   41 +-
  board/davinci/common/misc.h   |2 +-
  board/davinci/da8xxevm/da830evm.c |   12 +-
  board/davinci/dm365evm/dm365evm.c |2 +-
  board/davinci/dvevm/dvevm.c   |2 +-
  board/davinci/sffsdr/sffsdr.c |2 +-
  board/davinci/sonata/sonata.c |2 +-
  common/cmd_net.c  |2 +
  drivers/net/Makefile  |1 +
  drivers/net/at91_emac.c   |   20 +-
  drivers/net/davinci_emac.c|   80 +-
  drivers/net/enc28j60.c| 1548 -
  drivers/net/enc28j60.h|  251 
  drivers/net/enc28j60_lpc2292.c|  983 
  drivers/net/mpc5xxx_fec.c |7 +
  drivers/net/smc9.c|   40 +-
  drivers/net/xilinx_emaclite.c |   88 +-
  drivers/qe/uec.c  |4 +-
  drivers/qe/uec_phy.c  |   10 +-
  include/config_cmd_all.h  |1 +
  include/configs/SMN42.h   |2 +-
  include/configs/lpc2292sodimm.h   |2 +-
  include/netdev.h  |4 +-
  net/Makefile  |2 +-
  net/eth.c |   16 +-
  net/net.c |   11 +-
  28 files changed, 2192 insertions(+), 963 deletions(-)
  create mode 100644 drivers/net/enc28j60.h
  create mode 100644 drivers/net/enc28j60_lpc2292.c


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] net: Move Emaclite to NET_MULTI

[Ben Warren]

  Hi Michal,

On 10/10/2010 6:41 PM, Michal Simek wrote:
> Emaclite was using old net api that's why
> this patch move emaclite to NET_MULTI api.
>
> Signed-off-by: Michal Simek
> CC: Ben Warren
>
> ---
>
> v2: Pass base_addr as parameter
>
> v1: Initial version
> ---
>   drivers/net/xilinx_emaclite.c |   84 
> +++--
>   include/netdev.h  |1 +
>   2 files changed, 48 insertions(+), 37 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Fix emaclite driver to support little-endian microblaze

[Ben Warren]

  Hi Michal,

On 10/10/2010 6:41 PM, Michal Simek wrote:
> Support New emaclite AXI IP.
>
> Signed-off-by: Michal Simek
> CC: Ben Warren
> ---
>   drivers/net/xilinx_emaclite.c |4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> index 455ce0c..76af939 100644
> --- a/drivers/net/xilinx_emaclite.c
> +++ b/drivers/net/xilinx_emaclite.c
> @@ -309,7 +309,7 @@ static int emaclite_recv(struct eth_device *dev)
>   #endif
>   }
>   /* Get the length of the frame that arrived */
> - switch(((in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0xC))&
> + switch(((ntohl(in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0xC)))&
>   0x )>>  16) {
>   case 0x806:
>   length = 42 + 20; /* FIXME size of ARP */
> @@ -317,7 +317,7 @@ static int emaclite_recv(struct eth_device *dev)
>   break;
>   case 0x800:
>   length = 14 + 14 +
> - (((in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0x10))&
> + (((ntohl(in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 
> 0x10)))&
>   0x)>>  16); /* FIXME size of IP packet */
>   debug ("IP Packet\n");
>   break;
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] drivers/net/at91_emac.c: change return values

[Ben Warren]

  HI Andreas,

On 10/7/2010 12:44 AM, Andreas Bießmann wrote:
> Some return values pretended correct pass. This patch changes them according
> to README.drivers.net. This patch changes e.g. command 'dhcp' to stop after
> errorneous autonegotiation.
>
> Signed-off-by: Andreas Bießmann
> ---
>   drivers/net/at91_emac.c |   18 +-
>   1 files changed, 9 insertions(+), 9 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] drivers/net/at91_emac.c: increase timeout for autonegotiation

[Ben Warren]

  Hi Andreas,

On 10/7/2010 12:44 AM, Andreas Bießmann wrote:
> This patch increases timeout for autonegotiation from 1 second to 3 seconds.
> Some boards (e.g. at91rm9200ek) did not negotiate within 1 second.
>
> Signed-off-by: Andreas Bießmann
> ---
>   drivers/net/at91_emac.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
> index ca2b16b..4626398 100644
> --- a/drivers/net/at91_emac.c
> +++ b/drivers/net/at91_emac.c
> @@ -220,7 +220,7 @@ static int at91emac_phy_reset(struct eth_device *netdev)
>   at91emac_write(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, MII_BMCR,
>   (BMCR_ANENABLE | BMCR_ANRESTART));
>
> - for (i = 0; i<  10 / 100; i++) {
> + for (i = 0; i<  3; i++) {
>   at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR,
>   MII_BMSR,&status);
>   if (status&  BMSR_ANEGCOMPLETE)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] smc91111: add write_hwaddr

[Ben Warren]

  Hi Thomas,

On 10/5/2010 6:16 PM, Thomas Chou wrote:
> Add smc_write_hwaddr() to set mac address.
> Clear dev before use.
>
> Signed-off-by: Thomas Chou
> ---
>   drivers/net/smc9.c |   40 
>   1 files changed, 24 insertions(+), 16 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] rarp: Condtionally compile rarp support

[Ben Warren]

  Hi Peter,

On 9/30/2010 9:25 AM, Peter Tyser wrote:
> Most people don't use the 'rarpboot' command, so only enable it when
> CONFIG_CMD_RARP is defined.
>
> Signed-off-by: Peter Tyser
> ---
>   common/cmd_net.c |2 ++
>   include/config_cmd_all.h |1 +
>   net/Makefile |2 +-
>   net/net.c|   11 +--
>   4 files changed, 13 insertions(+), 3 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/2][NEXT] davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr

[Ben Warren]

  Hi Ben,

On 9/23/2010 6:58 AM, Ben Gardiner wrote:
> This patch proposes to migrate the davinci_emac driver to using the
> eth_device->write_hwaddr function pointer as suggested by Ben Warren.
>
> All the davinci boards had the behaviour, prior to this patch, of
> sync'ing the environment variable enetaddr with the MAC address read
> from non-volatile storage on boot -- when the two locations disagreed,
> the environment variable value took precendence. This patch keeps the
> same behaviour but lets eth_initialize take care of it.
>
> This patch refactors davinci_emac setup in the boards so that the MAC
> address is read from non-volatile storage into the environment variable
> and then the environment variable value is use in eth_intialize. The
> only exception is the direct call to davinci_eth_set_mac_addr made by
> the da830evm board init which was changed into an assignment of the
> enetaddr field.
>
> Signed-off-by: Ben Gardiner
> Tested-by: Nick Thompson
> CC: Ben Warren
>
Added to net repo.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mpc5xxx_fec: add call to reset_phy() after PHY initialization

[Ben Warren]

  Hi Ilya,

On 8/19/2010 2:09 AM, Ilya Yanok wrote:
> Some boards need their board-specific PHY quirks to be called
> to PHY to work normally. As mpc5xxx_fec driver uses on demand
> PHY initialization and can even reinit PHY during normal operation
> we can't count on reset_phy() call from arch//lib/board.c
> (it is most likely called _before_ we init the PHY from the
> driver) so we need to add call to reset_phy() directly in the
> driver.
>
> Cc: Ben Warren
> Signed-off-by: Ilya Yanok
> ---
>   drivers/net/mpc5xxx_fec.c |7 +++
>   1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/mpc5xxx_fec.c b/drivers/net/mpc5xxx_fec.c
> index c88e596..bc8c922 100644
> --- a/drivers/net/mpc5xxx_fec.c
> +++ b/drivers/net/mpc5xxx_fec.c
> @@ -250,6 +250,13 @@ static int mpc5xxx_fec_init(struct eth_device *dev, bd_t 
> * bis)
>   mpc5xxx_fec_init_phy(dev, bis);
>
>   /*
> +  * Call board-specific PHY fixups (if any)
> +  */
> +#ifdef CONFIG_RESET_PHY_R
> + reset_phy();
> +#endif
> +
> + /*
>* Initialize RxBD/TxBD rings
>*/
>   mpc5xxx_fec_rbd_init(fec);
Applied to net repo.  Please accept my sincere apologies for taking so 
long to process.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Coldfire Architecture and SELF

[Ben Warren]

Hello,

On Monday, September 27, 2010, SANCHEZ VITORICA, GUILLERMO
 wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi again,
>
>
>
> So, if I have got it
> straight, with VirtualBox + Ubuntu + ELDK + U-BOOT sources I can start
> developing U-BOOT for the MCF5445EVB?
>
>
Yes, that's how I'd do it if in your situation.

Regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Coldfire Architecture and SELF

[Ben Warren]

Hello,

On Mon, Sep 27, 2010 at 12:42 AM, Wolfgang Wegner wrote:

> Hi,
>
> On Mon, Sep 27, 2010 at 08:43:00AM +0200, SANCHEZ VITORICA, GUILLERMO
> wrote:
> > Hi again,
> >
> > Thank you for your fast answers.
> >
> > Sorry. I was reading the manual in the U-Boot webpage and miss understood
> some of the topics. I just wanted to get the develop tools in order to
> compile and develop the U-Boot for the MCF54455. The manual points something
> (toolchain?) called ELDK that runs under Linux, but currently I'm tied to
> Windows as host. I don't know the version to install either since I can't
> find the Coldfire v4 architecture file in the FTP server.
> >
> > Any development platform or tip will be welcomed. By the way, right now I
> only have intalled CodeWarrior for Coldfire v7.2 and Code Composer Studio
> 3.3.1. Should I try with Codesourcery?
>
> of course, the best solution is to switch to Linux as a development
> host. ;-)
> There are many possibilities, but I think the second best possibility
> is using coLinux to set up a "virtual" Linux on top of your Windows box. *)
> In this virtual Linux, you can do anything you would do in a native
> Linux box, including using LTIB and ELDK (is there a version of the
> latter for coldfire meanwhile?!).
>
> Better yet, just install Virtual Box (virtualbox.org) and Ubuntu.  Compile
time might be a bit slower than coLinux, but it's s easy.


> Setting up coLinux on your own can be a bit tricky. Maybe somebody can
> recommend a pre-built image for it that does not have some strange
> non-standard default settings?
>

Regards,
> Wolfgang
>

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] NET: add ENC28J60 driver using SPI framework

[Ben Warren]

Hi Mike,

On Mon, Sep 20, 2010 at 10:52 PM, Mike Frysinger  wrote:

> On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote:
> > > On Monday, September 20, 2010 17:44:38 Mike Frysinger wrote:
> > >> finally got around to testing this.  seems like the init needs some
> > >> work. if i power on the system (cold boot), boot Linux over the
> on-chip
> > >> mac, and let Linux program the enc part, it works fine under Linux.
> > >> then i do a software reset back into u-boot, it can use the enc fine
> > >> too.
> > >>
> > >> but if i cold boot u-boot and try to use the enc part, i get:
> > >>timeout waiting for CLKRDY
> > >>
> > >> enabling DEBUG doesnt show any additional output though.
> > >
> > > comparing the linux and u-boot drivers leads me to this fix:
> > >
> > > --- a/drivers/net/enc28j60.c
> > > +++ b/drivers/net/enc28j60.c
> > > @@ -632,6 +632,8 @@ static int enc_clock_wait(enc_dev_t *enc)
> > >
> > >   {
> > >
> > > uint64_t etime;
> > >
> > > +   enc_bclr(enc, CTL_REG_ECON2, ENC_ECON2_PWRSV);
> > > +
> > >
> > > /* one second timeout */
> > >
> > > etime = get_ticks() + get_tbclk();
> >
> > The Bit PWRSV is cleared (according to data sheet) on every Reset.
> > If that patch really helps in your case either the data sheet is wrong
> > (for your mask of the chip) OR there is another reason while the timeout
> > occurs in your case (I never had this timeout).
> >
> > I don't mind explicitly clearing this bit, but I suspect that this just
> > covers another problem.
> >
> > Could you read and print ECON2 in your case and see if PWRSV is really
> set?
>
> well, now i cant reproduce the issue, cold or warm booting :/.  so i guess
> ignore this change until i can reproduce things and get a register dump.
>
> although, earlier i was testing when the sun was out and shining on the
> board
> but now it's night, so maybe it's a cold-blooded part :x.
>
> i looked at the linux driver again and i think i misread it.  it isnt
> clearing
> ECON2 at reset, just when leaving low power mode.  it clears ECON1 after
> doing
> a soft reset.
>
> If you change your mind later, let me know and I'll squash this into the
earlier one.

> > Or, does the timeout really come to be 1 second - does get_tbclk()
> > really return the timer increments per second? On many architectures
> > get_tblck() simply returns CONFIG_SYS_HZ and not the number of timer
> > increments per second (which can be a different and much higher value).
>
> the Blackfin timer is just fine thanks :P.  it was pausing about 1 second
> between display of "enc0.18" and "CLKRDY timeout".  it wasnt an
> instantaneous
> display of the two lines.
> -mike
>
> regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] da850evm: basic MII EMAC support

[Ben Warren]

Hi Ben,

On Monday, September 13, 2010, Ben Gardiner  wrote:
> Hi Ben,
>
> On Sun, Sep 12, 2010 at 11:45 PM, Ben Warren  
> wrote:
>> Please consider doing this differently.  If you change the driver to make
>> 'davinci_eth_set_mac_addr()' meet the signature of
>> 'eth_device->write_hwaddr()', all the environment handling is done
>> automagically.  Let me know if you're confused and I'll provide more
>> guidance.
>
> Thanks for pointing me in the right direction here. I think I get it
> now; please correct me if I am wrong: board_eth_init should assign the
> eth_device->write_hwaddr() function pointer then eth_initialize() will
> handle calling board_eth_init and will set the MAC address from the
> ethaddr env var if the MAC address in the eth_device struct is
> all-zeroes.
>
Almost.  The driver should set the function pointer, just as it does
'send()', 'init()', 'halt()', etc.  This is a recent feature and the
davinci driver hasn't been updated yet
> Best Regards,
> Ben Gardiner
>
> ---
> Nanometrics Inc.
> http://www.nanometrics.ca

Regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC][PATCH 2/3] e1000: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Ben Warren]

  On 9/12/2010 9:24 PM, Kyle Moffett wrote:
> Ben,
>
> I am so sorry... please actually drop this patch.  I've been in 
> contact with Intel regarding the equivalent patch for the Linux kernel 
> and it turns out this is just a workaround for a misconfiguration in 
> our EEPROMs.  The boards on which I have fixed the EEPROMs do not need 
> this change in order to operate correctly.
>
> I am also finishing up a group of patches which allow us to more 
> easily program and manage those EEPROMs from U-Boot which I plan to 
> submit some time in the next few days; I will make sure to put you on 
> the CC list for them.
>
> Again, my apologies for the trouble!
>
> Cheers,
> Kyle Moffett
>
OK, no worries.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] NET: add ENC28J60 driver using SPI framework

[Ben Warren]

  Hi Reinhard,

On 9/12/2010 7:23 AM, Reinhard Meyer wrote:
> V3: further refinements:
> - use priv member instead of container method
> - allow setting of MAC address by write_hwaddr method
> - avoid shutting down link between commands
>
> Signed-off-by: Reinhard Meyer
> ---
Interesting driver...  Thanks for all the hard work.

Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.

[Ben Warren]

  Hi Jocke,

On 8/10/2010 7:36 AM, Joakim Tjernlund wrote:
> Instead of always performing an autoneg, check if the PHY
> already has a link and if it matches one of the requested
> modes. Initially only 100MbFD is optimized this way.
>
> Signed-off-by: Joakim Tjernlund
> ---
>   drivers/qe/uec_phy.c |9 +
>   1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/qe/uec_phy.c b/drivers/qe/uec_phy.c
> index 3baffe4..5237960 100644
> --- a/drivers/qe/uec_phy.c
> +++ b/drivers/qe/uec_phy.c
> @@ -351,6 +351,15 @@ static int marvell_config_aneg (struct uec_mii_info 
> *mii_info)
>   static int genmii_config_aneg (struct uec_mii_info *mii_info)
>   {
>   if (mii_info->autoneg) {
> + /* Speed up the common case, if link is already up, speed and
> +duplex match, skip auto neg as it already matches */
> + if (!genmii_read_status(mii_info)&&  mii_info->link)
> + if (mii_info->duplex == DUPLEX_FULL&&
> + mii_info->speed == SPEED_100)
> + if (mii_info->advertising&
> + ADVERTISED_100baseT_Full)
> + return 0;
> +
>   config_genmii_advert (mii_info);
>   genmii_restart_aneg (mii_info);
>   } else
Applied to net/next

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC][PATCH 2/3] e1000: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips

[Ben Warren]

  Hi Kyle,

On 8/30/2010 11:24 AM, Kyle Moffett wrote:
> The Intel 82571EB chipset can be used in an unmanaged configuration as a
> fast dual-port Gig-E controller.  Unfortunately a board consturcted that
> way would fail to correctly come up because the driver polls for the
> completion of a management cycle that will never occur.
>
> To resolve this problem, we disable the poll and error return on chips
> whose EEPROMS indicate no management.  As a protection against
> misconfigured chipsets, we still delay for the entire management poll
> timeout.
>
> Signed-off-by: Kyle Moffett
> ---
> Jeff Kirsher  has already accepted a similar
> patch to the Linux kernel into his e1000e patch queue.
>
>   drivers/net/e1000.c |7 +++
>   1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index 2825342..c9677b4 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -4266,6 +4266,13 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
>   /* Fall Through */
>   case e1000_82571:
>   case e1000_82572:
> + /* Don't bother polling the management regs if unmanaged */
> + if (!e1000_check_mng_mode(hw)) {
> + DEBUGOUT("Unmanaged chip... skipping MNG polling\n");
> + mdelay(timeout);
> + return 0;
> + }
> +
>   while (timeout) {
>   if (E1000_READ_REG(hw, EEMNGCTL)&  cfg_mask)
>   break;
Applied to net/next after fixing typo in prologue (see if you can find it)

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH NET 1/2] Net: Remove redundant CONFIG_NET_MULTI directives

[Ben Warren]

  On 8/31/2010 11:05 PM, Ben Warren wrote:
> All are within an #ifdef CONFIG_NET_MULTI block already
>
> Signed-off-by: Ben Warren
> ---
>   net/eth.c |   16 
>   1 files changed, 4 insertions(+), 12 deletions(-)
Applied to net/next

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] da850evm: basic MII EMAC support

[Ben Warren]

  Hi Ben,

On 9/10/2010 1:10 PM, Ben Gardiner wrote:
> The current da850evm support in u-boot/master [1] omits any use of
> the davinci EMAC. This patch adds basic support for the EMAC using
> the MII PHY found on the baseboard of the EVM. The MAC address is
> read from the environment variable 'ethadd'. Note that this is
> different from the da850evm support in the u-boot omapl1 tree
> where the MAC address is read from SPI flash [2].
>
> CC: Sandeep Paulraj
> CC: Sudhakar Rajashekhara
>
> [1] http://git.denx.de/?p=u-boot.git
> [2] http://arago-project.org/git/projects/?p=u-boot-omapl1.git
>
> ---
>
> I am submitting this patch for inclusion in v2010.12, not v2010.09 since it
> introduces a new feature.
>
> ---
>   board/davinci/da8xxevm/da850evm.c |   60 
> +
>   include/configs/da850evm.h|   15 +
>   2 files changed, 75 insertions(+), 0 deletions(-)
>
> diff --git a/board/davinci/da8xxevm/da850evm.c 
> b/board/davinci/da8xxevm/da850evm.c
> index eeb456c..30645e5 100644
> --- a/board/davinci/da8xxevm/da850evm.c
> +++ b/board/davinci/da8xxevm/da850evm.c
> @@ -23,7 +23,11 @@
>
>   #include
>   #include
> +#include
> +#include
>   #include
> +#include
> +#include
>   #include
>   #include "../common/misc.h"
>   #include "common.h"
> @@ -48,6 +52,28 @@ static const struct pinmux_config uart_pins[] = {
>   { pinmux(4), 2, 5 }
>   };
>
> +#ifdef CONFIG_DRIVER_TI_EMAC
> +const struct pinmux_config emac_pins[] = {
> + { pinmux(2), 8, 1 },
> + { pinmux(2), 8, 2 },
> + { pinmux(2), 8, 3 },
> + { pinmux(2), 8, 4 },
> + { pinmux(2), 8, 5 },
> + { pinmux(2), 8, 6 },
> + { pinmux(2), 8, 7 },
> + { pinmux(3), 8, 0 },
> + { pinmux(3), 8, 1 },
> + { pinmux(3), 8, 2 },
> + { pinmux(3), 8, 3 },
> + { pinmux(3), 8, 4 },
> + { pinmux(3), 8, 5 },
> + { pinmux(3), 8, 6 },
> + { pinmux(3), 8, 7 },
> + { pinmux(4), 8, 0 },
> + { pinmux(4), 8, 1 }
> +};
> +#endif /* CONFIG_DRIVER_TI_EMAC */
> +
>   /* I2C pin muxer settings */
>   static const struct pinmux_config i2c_pins[] = {
>   { pinmux(4), 2, 2 },
> @@ -102,6 +128,14 @@ int board_init(void)
>   if (davinci_configure_pin_mux_items(pinmuxes, ARRAY_SIZE(pinmuxes)))
>   return 1;
>
> +#ifdef CONFIG_DRIVER_TI_EMAC
> + if (davinci_configure_pin_mux(emac_pins, ARRAY_SIZE(emac_pins)) != 0)
> + return 1;
> + /* set cfgchip3 to select MII */
> + writel(readl(&davinci_syscfg_regs->cfgchip3)&  ~(1<<  8),
> + &davinci_syscfg_regs->cfgchip3);
> +#endif /* CONFIG_DRIVER_TI_EMAC */
> +
>   /* enable the console UART */
>   writel((DAVINCI_UART_PWREMU_MGMT_FREE | DAVINCI_UART_PWREMU_MGMT_URRST |
>   DAVINCI_UART_PWREMU_MGMT_UTRST),
> @@ -109,3 +143,29 @@ int board_init(void)
>
>   return 0;
>   }
> +
> +#ifdef CONFIG_DRIVER_TI_EMAC
> +
> +/*
> + * Initializes on-board ethernet controllers.
> + */
> +int board_eth_init(bd_t *bis)
> +{
> + u_int8_t mac_addr[6];
> +
> + /* read the address from env */
> + if (!eth_getenv_enetaddr("ethaddr", mac_addr))
> + return -1;
> +
> + /* provide the resulting addr to the driver */
> + davinci_eth_set_mac_addr(mac_addr);
> +
> + /* finally, initialise the driver */
> + if (!davinci_emac_initialize()) {
> + printf("Error: Ethernet init failed!\n");
> + return -1;
> + }
> +
Please consider doing this differently.  If you change the driver to 
make 'davinci_eth_set_mac_addr()' meet the signature of 
'eth_device->write_hwaddr()', all the environment handling is done 
automagically.  Let me know if you're confused and I'll provide more 
guidance.
> + return 0;
> +}
> +#endif /* CONFIG_DRIVER_TI_EMAC */
> diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
> index 357715d..432c5e6 100644
> --- a/include/configs/da850evm.h
> +++ b/include/configs/da850evm.h
> @@ -26,6 +26,7 @@
>   /*
>* Board
>*/
> +#define CONFIG_DRIVER_TI_EMAC
>
>   /*
>* SoC Configuration
> @@ -79,6 +80,20 @@
>   #define CONFIG_SYS_I2C_SLAVE10 /* Bogus, master-only in 
> U-Boot */
>
>   /*
> + * Network&  Ethernet Configuration
> + */
> +#ifdef CONFIG_DRIVER_TI_EMAC
> +#define CONFIG_EMAC_MDIO_PHY_NUM 0
> +#define CONFIG_MII
> +#define CONFIG_BOOTP_DEFAULT
> +#define CONFIG_BOOTP_DNS
> +#define CONFIG_BOOTP_DNS2
> +#define CONFIG_BOOTP_SEND_HOSTNAME
> +#define CONFIG_NET_RETRY_COUNT   10
> +#define CONFIG_NET_MULTI
> +#endif
> +
> +/*
>* U-Boot general configuration
>*/
>   #define CONFIG_BOOTFILE "uImage" /* Boot file name */
regards,
Ben W.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] v2010.09-rc1 is out / v2010.09 delayed by 2 weeks

[Ben Warren]

  On 9/12/2010 12:18 PM, Mike Frysinger wrote:
> On Sunday, September 12, 2010 08:58:29 Reinhard Meyer wrote:
>> 1110f276e9785d0270cfc9ec316dd475145f95d0 SPI: cmd_spi.c: add options to
>> specify bus and mode - has been posted 26.08.2010
> i already merged into my sf branch and will push post 2010.09 if Woflgang
> doesnt pick it up himself
>
>> 7c7e2813318b84fc4fbec57b23e2ad68ff000564 NET: move legacy enc28j60.c to
>> sidetrack - Ben took that one to net/next on 31.08.2010
> that's Ben's call to move from net to mainline ... and unless there's a
> pressing reason for this to be in mainline (i cant see any), keeping it for
> post release is OK ...
> -mike
Yeah, I don't see a compelling reason to bring this in now.  I'll send a 
pull request for next soon so the code gets to mainline early in the 
next cycle.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] TI: netdev: add driver for cpsw ethernet device

[Ben Warren]

  On 8/31/2010 8:58 AM, Cyril Chemparathy wrote:
> Hi Ben,
>
> [...]
>>> +COBJS-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o
>> Please don't use the word DRIVER here.  If possible, use something more
>> verbose than "CPSW" too.
> Will TI_CPSW_SWITCH work better considering that "CPSW" is the name of
> the hardware block?
>
Sure.
> [...]
>>> +++ b/drivers/net/cpsw.c
>> Please rename this ti_cpsw.c
> Agreed.
>
> [...]
>>> +struct cpsw_priv {
>>> + struct eth_device   *dev;
>>> + struct cpsw_platform_data   data;
>>> + int host_port;
>>> +
>>> + struct cpsw_regs*regs;
>>> + void*dma_regs;
>>> + struct cpsw_host_regs   *host_port_regs;
>>> + void*ale_regs;
>>> +
>>> + struct cpdma_desc   descs[NUM_DESCS];
>>> + struct cpdma_desc   *desc_free;
>>> + struct cpdma_chan   rx_chan, tx_chan;
>>> +
>>> + struct cpsw_slave   *slaves;
>>> +#define for_each_slave(priv, func, arg...)   \
>>> + do {\
>>> + int idx;\
>>> + for (idx = 0; idx<   (priv)->data.slaves; idx++) \
>>> + (func)((priv)->slaves + idx, ##arg);\
>>> + } while (0)
>>> +};
>>> +
>> Can this stuff go in a header file?
> This stuff is intended to be private within the driver.  I can split
> this out into drivers/net/ti_cpsw.h.
>
If it's truly private within the driver and will never be needed by 
anybody else, the source file is OK, but since you're going to create a 
new header file in /include/net anyway, maybe you'll want to put some 
stuff there.  Your call...
> [...]
>>> diff --git a/include/netdev.h b/include/netdev.h
>>> index 94eedfe..009e2f1 100644
>>> --- a/include/netdev.h
>>> +++ b/include/netdev.h
>>> @@ -180,4 +180,33 @@ struct mv88e61xx_config {
>>>int mv88e61xx_switch_initialize(struct mv88e61xx_config *swconfig);
>>>#endif /* CONFIG_MV88E61XX_SWITCH */
>>>
>>> +#ifdef CONFIG_DRIVER_TI_CPSW
>>> +
>>> +struct cpsw_slave_data {
>>> + u32 slave_reg_ofs;
>>> + u32 sliver_reg_ofs;
>>> + int phy_id;
>>> +};
>>> +
>>> +struct cpsw_platform_data {
>>> + u32 mdio_base;
>>> + u32 cpsw_base;
>>> + int mdio_div;
>>> + int channels;   /* number of cpdma channels (symmetric) */
>>> + u32 cpdma_reg_ofs;  /* cpdma register offset*/
>>> + int slaves; /* number of slave cpgmac ports */
>>> + u32 ale_reg_ofs;/* address lookup engine reg offset */
>>> + int ale_entries;/* ale table size   */
>>> + u32 host_port_reg_ofs;  /* cpdma host port registers*/
>>> + u32 hw_stats_reg_ofs;   /* cpsw hw stats counters   */
>>> + u32 mac_control;
>>> + struct cpsw_slave_data  *slave_data;
>>> + void(*control)(int enabled);
>>> + void(*phy_init)(char *name, int addr);
>>> +};
>>> +
>> This stuff doesn't belong in this file.  Definitions specific to your
>> driver should go in /include/net/ti_cpsw.h (note that you'll be creating
>> this directory, but that's where we want driver headers to go moving
>> forward.  Also, please call the initialize function
>> 'ti_cpsw_initialize()'.  Despite what the readme file recommends, you're
>> initializing something, not registering it.  If anything, the 'init()'
>> functions are misnamed, but that's another discussion.
> Will do.
>
> We will post an updated v2 series shortly, with these changes.
>
> Thanks
> Cyril.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] TI: netdev: add driver for cpsw ethernet device

[Ben Warren]

  Hi Cyril,

On 9/1/2010 8:34 AM, Cyril Chemparathy wrote:
> Hi Ben,
>
> I seem to have missed a comment while responding earlier:
>
> [...]
>>> +int cpsw_register(struct cpsw_platform_data *data)
>> Please redo things so that this function takes generic arguments.  Build
>> up your struct internally.
> Could you elaborate on the generic arguments here?  Are you referring to
> the eth_device struct and bd_t args?
>
By generic I mean primitive, or structs that are defined in headers that 
are universally included.  Ideally, you'll pass in arguments that don't 
require another header file to resolve, such as a base address or index 
number.  As you've proposed, anybody that includes  will need 
to know what a 'struct cpsw_platform_data' is, and that's not appropriate.
> Regards
> Cyril.
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH NET 2/2] Net: clarify board/cpu_eth_init calls

[Ben Warren]

  Hi Mike,

On 9/1/2010 10:04 AM, Mike Frysinger wrote:
> On Wednesday, September 01, 2010 02:05:04 Ben Warren wrote:
>> +if (board_eth_init != __def_eth_init) {
>> +} else if (cpu_eth_init != __def_eth_init) {
> i'm not sure these changes are useful.  the resolution of the symbols happens
> at link time, so it isnt like gcc will be able to optimize away the default.
>
> if anything, it'd make more sense to declare the functions as external/weak,
> and then check that the pointer is not NULL.  that'd save on the overhead of
> having uncalled stub functions that merely return 0 in the final linked image.
> -mike
This did work as I hoped on my PPC eval board, but maybe not globally.  
I remember that initially, with the functions defined as weak but with 
no body, check for NULL didn't work.  I've never tried declaring them as 
external, though.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH NET 2/2] Net: clarify board/cpu_eth_init calls

[Ben Warren]

This has always been confusing, and the idea of these functions returning the
number of interfaces initialized was half-baked and ultimately pointless.
Instead, act more like regular functions and return < 0 on failure, >= 0 on
success.

This change shouldn't break anything.

Signed-off-by: Ben Warren 
---
 net/eth.c |   16 
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/net/eth.c b/net/eth.c
index 5c70d4f..6082c90 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -204,10 +204,18 @@ int eth_initialize(bd_t *bis)
 #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_init();
 #endif
-   /* Try board-specific initialization first.  If it fails or isn't
-* present, try the cpu-specific initialization */
-   if (board_eth_init(bis) < 0)
-   cpu_eth_init(bis);
+   /*
+* If board-specific initialization exists, call it.
+* If not, call a CPU-specific one
+*/
+   if (board_eth_init != __def_eth_init) {
+   if (board_eth_init(bis) < 0)
+   printf("Board Net Initialization Failed\n");
+   } else if (cpu_eth_init != __def_eth_init) {
+   if (cpu_eth_init(bis) < 0)
+   printf("CPU Net Initialization Failed\n");
+   } else
+   printf("Net Initialization Skipped\n");
 
 #if defined(CONFIG_DB64360) || defined(CONFIG_CPCI750)
mv6436x_eth_initialize(bis);
-- 
1.6.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH NET 1/2] Net: Remove redundant CONFIG_NET_MULTI directives

[Ben Warren]

All are within an #ifdef CONFIG_NET_MULTI block already

Signed-off-by: Ben Warren 
---
 net/eth.c |   16 
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/net/eth.c b/net/eth.c
index 993306f..5c70d4f 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -263,7 +263,6 @@ int eth_initialize(bd_t *bis)
dev = dev->next;
} while(dev != eth_devices);
 
-#ifdef CONFIG_NET_MULTI
/* update current ethernet name */
if (eth_current) {
char *act = getenv("ethact");
@@ -271,7 +270,6 @@ int eth_initialize(bd_t *bis)
setenv("ethact", eth_current->name);
} else
setenv("ethact", NULL);
-#endif
 
putc ('\n');
}
@@ -441,7 +439,7 @@ int eth_receive(volatile void *packet, int length)
 void eth_try_another(int first_restart)
 {
static struct eth_device *first_failed = NULL;
-   char *ethrotate;
+   char *ethrotate, *act;
 
/*
 * Do not rotate between network interfaces when
@@ -460,21 +458,16 @@ void eth_try_another(int first_restart)
 
eth_current = eth_current->next;
 
-#ifdef CONFIG_NET_MULTI
/* update current ethernet name */
-   {
-   char *act = getenv("ethact");
-   if (act == NULL || strcmp(act, eth_current->name) != 0)
-   setenv("ethact", eth_current->name);
-   }
-#endif
+   act = getenv("ethact");
+   if (act == NULL || strcmp(act, eth_current->name) != 0)
+   setenv("ethact", eth_current->name);
 
if (first_failed == eth_current) {
NetRestartWrap = 1;
}
 }
 
-#ifdef CONFIG_NET_MULTI
 void eth_set_current(void)
 {
static char *act = NULL;
@@ -501,7 +494,6 @@ void eth_set_current(void)
 
setenv("ethact", eth_current->name);
 }
-#endif
 
 char *eth_get_name (void)
 {
-- 
1.6.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] net: Move Emaclite to NET_MULTI

[Ben Warren]

  Hi Michal,

Sorry for the delay in reviewing

On 8/2/2010 5:49 AM, Michal Simek wrote:
> Emaclite was using old net api that's why
> this patch move emaclite to NET_MULTI api.
>
> Signed-off-by: Michal Simek
> ---
>   drivers/net/xilinx_emaclite.c |   84 
> +++--
>   include/netdev.h  |1 +
>   2 files changed, 48 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> index 0820daa..f460525 100644
> --- a/drivers/net/xilinx_emaclite.c
> +++ b/drivers/net/xilinx_emaclite.c
> @@ -26,6 +26,7 @@
>   #include
>   #include
>   #include
> +#include
>   #include
>
>   #undef DEBUG
> @@ -63,26 +64,19 @@
>   #define XEL_RSR_RECV_IE_MASK0x0008UL
>
>   typedef struct {
> - unsigned int baseaddress;   /* Base address for device (IPIF) */
> - unsigned int nexttxbuffertouse; /* Next TX buffer to write to */
> - unsigned int nextrxbuffertouse; /* Next RX buffer to read from */
> - unsigned char deviceid; /* Unique ID of device - for future */
> + u32 baseaddress;/* Base address for device (IPIF) */
> + u32 nexttxbuffertouse;  /* Next TX buffer to write to */
> + u32 nextrxbuffertouse;  /* Next RX buffer to read from */
> + uchar deviceid; /* Unique ID of device - for future */
>   } xemaclite;
>
>   static xemaclite emaclite;
>
>   static u32 etherrxbuff[PKTSIZE_ALIGN/4]; /* Receive buffer */
>
> -/* hardcoded MAC address for the Xilinx EMAC Core when env is nowhere*/
> -#ifdef CONFIG_ENV_IS_NOWHERE
> -static u8 emacaddr[ENET_ADDR_LENGTH] = { 0x00, 0x0a, 0x35, 0x00, 0x22, 0x01 
> };
> -#else
> -static u8 emacaddr[ENET_ADDR_LENGTH];
> -#endif
> -
> -void xemaclite_alignedread (u32 * srcptr, void *destptr, unsigned bytecount)
> +static void xemaclite_alignedread (u32 *srcptr, void *destptr, u32 bytecount)
>   {
> - unsigned int i;
> + u32 i;
>   u32 alignbuffer;
>   u32 *to32ptr;
>   u32 *from32ptr;
> @@ -107,9 +101,9 @@ void xemaclite_alignedread (u32 * srcptr, void *destptr, 
> unsigned bytecount)
>   }
>   }
>
> -void xemaclite_alignedwrite (void *srcptr, u32 destptr, unsigned bytecount)
> +static void xemaclite_alignedwrite (void *srcptr, u32 destptr, u32 bytecount)
>   {
> - unsigned i;
> + u32 i;
>   u32 alignbuffer;
>   u32 *to32ptr = (u32 *) destptr;
>   u32 *from32ptr;
> @@ -134,23 +128,16 @@ void xemaclite_alignedwrite (void *srcptr, u32 destptr, 
> unsigned bytecount)
>   *to32ptr++ = alignbuffer;
>   }
>
> -void eth_halt (void)
> +static void emaclite_halt(struct eth_device *dev)
>   {
>   debug ("eth_halt\n");
>   }
>
> -int eth_init (bd_t * bis)
> +static int emaclite_init(struct eth_device *dev, bd_t *bis)
>   {
> - uchar enetaddr[6];
> -
>   debug ("EmacLite Initialization Started\n");
>   memset (&emaclite, 0, sizeof (xemaclite));
> - emaclite.baseaddress = XILINX_EMACLITE_BASEADDR;
> -
> - if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
> - memcpy(enetaddr, emacaddr, ENET_ADDR_LENGTH);
> - eth_setenv_enetaddr("ethaddr", enetaddr);
> - }
> + emaclite.baseaddress = dev->iobase;
>
>   /*
>* TX - TX_PING&  TX_PONG initialization
> @@ -158,7 +145,7 @@ int eth_init (bd_t * bis)
>   /* Restart PING TX */
>   out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET, 0);
>   /* Copy MAC address */
> - xemaclite_alignedwrite (enetaddr,
> + xemaclite_alignedwrite (dev->enetaddr,
>   emaclite.baseaddress, ENET_ADDR_LENGTH);
>   /* Set the length */
>   out_be32 (emaclite.baseaddress + XEL_TPLR_OFFSET, ENET_ADDR_LENGTH);
> @@ -171,7 +158,7 @@ int eth_init (bd_t * bis)
>   #ifdef CONFIG_XILINX_EMACLITE_TX_PING_PONG
>   /* The same operation with PONG TX */
>   out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET + XEL_BUFFER_OFFSET, 0);
> - xemaclite_alignedwrite (enetaddr, emaclite.baseaddress +
> + xemaclite_alignedwrite (dev->enetaddr, emaclite.baseaddress +
>   XEL_BUFFER_OFFSET, ENET_ADDR_LENGTH);
>   out_be32 (emaclite.baseaddress + XEL_TPLR_OFFSET, ENET_ADDR_LENGTH);
Please consider moving this stuff to a separate function.  If you bind 
it to dev->write_hwaddr(), programming will occur at initialization time.
>   out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET + XEL_BUFFER_OFFSET,
> @@ -194,7 +181,7 @@ int eth_init (bd_t * bis)
>   return 0;
>   }
>
> -int xemaclite_txbufferavailable (xemaclite * instanceptr)
> +static int xemaclite_txbufferavailable (xemaclite *instanceptr)
>   {
>   u32 reg;
>   u32 txpingbusy;
> @@ -216,12 +203,12 @@ int xemaclite_txbufferavailable (xemaclite * 
> instanceptr)
>   return (!(txpingbusy&&  txpongbusy));
>   }
>
> -int eth_send (volatile void *ptr, int len) {
> -
> - unsigned int reg;
> - unsigned int baseaddress;
> +static int emaclite_send (struct eth_device *dev, volatile void *ptr, int 
> len)
> +

Re: [U-Boot] [PATCHv2] net: Fix faulty definition of uec_initialize()

[Ben Warren]

  Hi Jocke,

On 8/19/2010 12:37 AM, Joakim Tjernlund wrote:
> The correct definition is in drivers/qe/uec.h so just
> remove this one.
>
> Signed-off-by: Joakim Tjernlund
> ---
>   include/netdev.h |1 -
>   1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/include/netdev.h b/include/netdev.h
> index 882642a..65833e2 100644
> --- a/include/netdev.h
> +++ b/include/netdev.h
> @@ -83,7 +83,6 @@ int skge_initialize(bd_t *bis);
>   int smc911x_initialize(u8 dev_num, int base_addr);
>   int smc9_initialize(u8 dev_num, int base_addr);
>   int tsi108_eth_initialize(bd_t *bis);
> -int uec_initialize(int index);
>   int uec_standard_init(bd_t *bis);
>   int uli526x_initialize(bd_t *bis);
>   int sh_eth_initialize(bd_t *bis);
Applied to net/next

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] UEC: Don't udelay needlessly

[Ben Warren]

  Hi Jocke,

On 8/11/2010 2:44 AM, Joakim Tjernlund wrote:
> uec_init() adds an udelay(10) even though
> the PHY status read went well, don't do that.
>
> Signed-off-by: Joakim Tjernlund
> ---
>   drivers/qe/uec.c |4 +++-
>   1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
> index ccbf27d..758151f 100644
> --- a/drivers/qe/uec.c
> +++ b/drivers/qe/uec.c
> @@ -1223,8 +1223,10 @@ static int uec_init(struct eth_device* dev, bd_t *bd)
>   i = 50;
>   do {
>   err = curphy->read_status(uec->mii_info);
> + if (!(((i-->  0)&&  !uec->mii_info->link) || err))
> + break;
>   udelay(10);
> - } while (((i-->  0)&&  !uec->mii_info->link) || err);
> + } while (1);
>
>   if (err || i<= 0)
>   printf("warning: %s: timeout on PHY link\n", dev->name);
Parts 1 & 2 applied to net/next.  Sorry for taking so long.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] NET: move legacy enc28j60.c to sidetrack as enc28j60_lpc2292.c

[Ben Warren]

  Hello Reinhard,

On 8/6/2010 9:42 AM, Reinhard Meyer (-VC) wrote:
> This patch is required before the upcoming new enc28j60 driver
> using SPI framework patch can be applied:
> - Move legacy enc28j60.c to enc28j60_lpc2292.c.
> - Change Makefile and the two affected boards' definition files.
>
> Tested with ./MAKEALL ARM7 that both boards still compile.
>
> Signed-off-by: Reinhard Meyer
> ---
Applied to net/next

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] TI: netdev: add driver for cpsw ethernet device

[Ben Warren]

  Hi Cyril,

Sorry for taking so long to look at this.

On 8/3/2010 6:33 PM, Cyril Chemparathy wrote:
> CPSW is an on-chip ethernet switch that is found on various SoCs from Texas
> Instruments.  This patch adds a simple driver (based on the Linux driver) for
> this hardware module.
>
> Signed-off-by: Cyril Chemparathy
> ---
>   drivers/net/Makefile |1 +
>   drivers/net/cpsw.c   |  861 
> ++
>   include/netdev.h |   29 ++
>   3 files changed, 891 insertions(+), 0 deletions(-)
>   create mode 100644 drivers/net/cpsw.c
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 218eeff..f4f1ed2 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -73,6 +73,7 @@ COBJS-$(CONFIG_SMC9) += smc9.o
>   COBJS-$(CONFIG_SMC911X) += smc911x.o
>   COBJS-$(CONFIG_TIGON3) += tigon3.o bcm570x_autoneg.o 5701rls.o
>   COBJS-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
> +COBJS-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o
Please don't use the word DRIVER here.  If possible, use something more 
verbose than "CPSW" too.
>   COBJS-$(CONFIG_TSEC_ENET) += tsec.o
>   COBJS-$(CONFIG_TSI108_ETH) += tsi108_eth.o
>   COBJS-$(CONFIG_ULI526X) += uli526x.o
> diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
> new file mode 100644
> index 000..c84ec78
> --- /dev/null
> +++ b/drivers/net/cpsw.c
Please rename this ti_cpsw.c
> @@ -0,0 +1,861 @@
> +/*
> + * CPSW Ethernet Switch Driver
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BIT(x)   (1<<  (x))
> +#define BITMASK(bits)(BIT(bits) - 1)
> +#define PHY_REG_MASK 0x1f
> +#define PHY_ID_MASK  0x1f
> +#define NUM_DESCS(PKTBUFSRX * 2)
> +#define PKT_MIN  60
> +#define PKT_MAX  (1500 + 14 + 4 + 4)
> +
> +/* DMA Registers */
> +#define CPDMA_TXCONTROL  0x004
> +#define CPDMA_RXCONTROL  0x014
> +#define CPDMA_SOFTRESET  0x01c
> +#define CPDMA_RXFREE 0x0e0
> +#define CPDMA_TXHDP  0x100
> +#define CPDMA_RXHDP  0x120
> +#define CPDMA_TXCP   0x140
> +#define CPDMA_RXCP   0x160
> +
> +/* Descriptor mode bits */
> +#define CPDMA_DESC_SOP   BIT(31)
> +#define CPDMA_DESC_EOP   BIT(30)
> +#define CPDMA_DESC_OWNER BIT(29)
> +#define CPDMA_DESC_EOQ   BIT(28)
> +
> +struct cpsw_mdio_regs {
> + u32 version;
> + u32 control;
> +#define CONTROL_IDLE (1<<  31)
> +#define CONTROL_ENABLE   (1<<  30)
> +
> + u32 alive;
> + u32 link;
> + u32 linkintraw;
> + u32 linkintmasked;
> + u32 __reserved_0[2];
> + u32 userintraw;
> + u32 userintmasked;
> + u32 userintmaskset;
> + u32 userintmaskclr;
> + u32 __reserved_1[20];
> +
> + struct {
> + u32 access;
> + u32 physel;
> +#define USERACCESS_GO(1<<  31)
> +#define USERACCESS_WRITE (1<<  30)
> +#define USERACCESS_ACK   (1<<  29)
> +#define USERACCESS_READ  (0)
> +#define USERACCESS_DATA  (0x)
> + } user[0];
> +};
> +
> +struct cpsw_regs {
> + u32 id_ver;
> + u32 control;
> + u32 soft_reset;
> + u32 stat_port_en;
> + u32 ptype;
> +};
> +
> +struct cpsw_slave_regs {
> + u32 max_blks;
> + u32 blk_cnt;
> + u32 flow_thresh;
> + u32 port_vlan;
> + u32 tx_pri_map;
> + u32 gap_thresh;
> + u32 sa_lo;
> + u32 sa_hi;
> +};
> +
> +struct cpsw_host_regs {
> + u32 max_blks;
> + u32 blk_cnt;
> + u32 flow_thresh;
> + u32 port_vlan;
> + u32 tx_pri_map;
> + u32 cpdma_tx_pri_map;
> + u32 cpdma_rx_chan_map;
> +};
> +
> +struct cpsw_sliver_regs {
> + u32 id_ver;
> + u32 mac_control;
> + u32 mac_status;
> + u32 soft_reset;
> + u32 rx_maxlen;
> + u32 __reserved_0;
> +   

Re: [U-Boot] UEC/NET patch status?

[Ben Warren]

  On 8/30/2010 2:22 PM, Joakim Tjernlund wrote:
> some time ago I submitted:
>
> [PATCH 1/2] UEC: Don't udelay needlessly
> [PATCH 2/2] UEC PHY: Remove strange 0.5 sec delay
> [PATCHv2] net: Fix faulty definition of uec_initialize()
> [PATCH] UEC PHY: Speed up initial PHY neg.
>
> The two first got an Ack from Kim, but the other two
> has not. None of them have showed up the the u-boot repo.
> I have tried to get some feedback(read prodding) but
> no such luck. The NET part in u-boot is moving really slow
> and I suspect my patches are already forgotten?
>
No, not forgotten, just in a queue.  I'm acutely aware that this is 
moving slowly, and will pull yours and other peoples stuff in *soon*.  
Sorry, but other things that do have open merge windows have gotten 
priority lately.
>   Jocke
>
regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?

[Ben Warren]

  Hi Grant,

On 8/23/2010 2:10 PM, Grant Edwards wrote:
> On 2010-08-23, Detlev Zundel  wrote:
>
> I didn't say that. I was trying to say that our bareboard system
> doesn't support Ethernet and does not have TCP/IP stack (like Linux).
> If our system was a Linux system, we wouldn't be having this
> conversation.
 We use tftp in U-Boot exactly because we also do not have a TCP/IP
 stack :)

 tftp needs only udp is thus "not too complex" to implement on bare
 ethernet.
>>> Doesn't "our bareboard system doesn't support Ethernet" preclude the
>>> use of Ethernet (UDP or otherwise)?
>> Yes, sorry.  I was mislead by the "and not the more efficient FTP
>> used in Linux".  The pure mentioning of FTP which does not make any
>> sense without a network port made me read the following statement not
>> close enough.
> I thought maybe I had lost track of who posted what. :)
>
 Maybe you can implement a server on your hardware?
>>> What sort of server?
>> It would be a tftp server of course but that is out of the question
>> without a network hardware.
> Now that you mention it, I have implemented a tftp server for U-Boot.
>
> We needed a way to recover "bricked" units in the field, and there's
> simply no way we could require out customers to install a tftp server
> on their machines.  Making U-Boot the tftp server and our "restore"
> program the client solved several problems.  I also find have U-Boot
> be the server is a lot more convenient for development use.  [It also
> U-Boot commands to be sent via the tftp protocol.]
>
> I thought about submitting patches (it's pretty much a stand-alone
> addition except for 3-4 lines in net.[ch]).  But it was made
> abundantly clear that tftp server code for U-Boot would never be
> considered -- I was scolded for even asking about it.
>
I can see how this could be useful.  Please reconsider and we'll try to 
keep the scolding to a minimum :)

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.

[Ben Warren]

Hi Jocke,

On Monday, August 23, 2010, Joakim Tjernlund
 wrote:
> Ben Warren  wrote on 2010/08/23 09:08:17:
>>
>>   Hi Detlev,
>>
>> On 8/13/2010 1:20 AM, Detlev Zundel wrote:
>> > Hi Jocke,
>> >
>> >>>> Instead of always performing an autoneg, check if the PHY
>> >>>> already has a link and if it matches one of the requested
>> >>>> modes. Initially only 100MbFD is optimized this way.
>> >>> Isn't it about time that we think about _not_ stopping the ethernet
>> >>> device after every transaction?
>> >> Hi Detlev
>> >>
>> >> UEC does this already, my patch was to address the initial delay
>> >> you get for the first transaction. Now my PHY based boards gets the link
>> >> up just as quick as Fixed PHY for the first transaction.
>> > Forgive me to not look into this any deeper, but do I understand you
>> > correctly that you do this by essentially no-oping the eth_halt()
>> > function?  Isn't this then effectively violating what net.c expects the
>> > device to do?
>> >
>> > I was thinking that net.c itself should not do this continous start/stop
>> > thing as it has problems on many interfaces.  On one ARM machine I've
>> > again seen problems with the MAC address programming because the
>> > eth_halt() resets the controller and so it forgets its address again.
>> > Also the USB-CDC example where the _whole interface_ on the host side is
>> > being torn down after each tftp transfer prompts me to think along this
>> > line.
>> >
>> > So in effect I guess my response was rather a ping to Ben, sorry for
>> > that ;)
>> >
>> Sorry for the delay on this.  I'm all for changing the existing
>> behavior.  It seems to me that the only time we would ever want to wind
>> an interface down is if we switch the active one (even then, I'm not
>> sure).  My world view is limited, but I can't imagine that even changing
>> interfaces happens much in real world U-boot usage, that is the non-lab,
>> non-interactive use cases.  What would you think about adding something
>> like ifup and ifdown commands so that users could explicitly start/stop
>> interfaces?
>
> Sure, bringing I/F's up and down needlessly isn't a good thing. However my
> patch doesn't change that behaviour. It only optimizes the need for a PHY AN
> the first time one performs a eth transaction.
>

I know.  I guess my e-mail was more directed towards Detlev's musings.
>       Jocke

Regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] UEC PHY: Speed up initial PHY neg.

[Ben Warren]

  Hi Detlev,

On 8/13/2010 1:20 AM, Detlev Zundel wrote:
> Hi Jocke,
>
 Instead of always performing an autoneg, check if the PHY
 already has a link and if it matches one of the requested
 modes. Initially only 100MbFD is optimized this way.
>>> Isn't it about time that we think about _not_ stopping the ethernet
>>> device after every transaction?
>> Hi Detlev
>>
>> UEC does this already, my patch was to address the initial delay
>> you get for the first transaction. Now my PHY based boards gets the link
>> up just as quick as Fixed PHY for the first transaction.
> Forgive me to not look into this any deeper, but do I understand you
> correctly that you do this by essentially no-oping the eth_halt()
> function?  Isn't this then effectively violating what net.c expects the
> device to do?
>
> I was thinking that net.c itself should not do this continous start/stop
> thing as it has problems on many interfaces.  On one ARM machine I've
> again seen problems with the MAC address programming because the
> eth_halt() resets the controller and so it forgets its address again.
> Also the USB-CDC example where the _whole interface_ on the host side is
> being torn down after each tftp transfer prompts me to think along this
> line.
>
> So in effect I guess my response was rather a ping to Ben, sorry for
> that ;)
>
Sorry for the delay on this.  I'm all for changing the existing 
behavior.  It seems to me that the only time we would ever want to wind 
an interface down is if we switch the active one (even then, I'm not 
sure).  My world view is limited, but I can't imagine that even changing 
interfaces happens much in real world U-boot usage, that is the non-lab, 
non-interactive use cases.  What would you think about adding something 
like ifup and ifdown commands so that users could explicitly start/stop 
interfaces?
> Cheers
>Detlev
>
regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] UEC: Don't udelay needlessly

[Ben Warren]

Hi Joakim,

On Wednesday, August 18, 2010, Joakim Tjernlund
 wrote:
>>
>> On Wed, 11 Aug 2010 11:44:21 +0200
>> Joakim Tjernlund  wrote:
>>
>> > uec_init() adds an udelay(10) even though
>> > the PHY status read went well, don't do that.
>> >
>> > Signed-off-by: Joakim Tjernlund 
>> > ---
>> Acked-by: Kim Phillips 
>>
>> Kim
>
> hmm, who gets this into the tree?
>
I'm just getting caught up, and will take this.

Regards,
Ben
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] tnetv107x cpsw ethernet switch driver

[Ben Warren]

  On 8/12/2010 6:26 PM, Mike Frysinger wrote:
> On Thu, Aug 12, 2010 at 7:05 PM, Ben Warren wrote:
>> I started looking at it a week ago and something came up.  My first
>> impression is that the driver needs an include file.  netdev.h is
>> reserved for device driver prototypes and common definitions.
> how about starting now with a standard like include/net/ ?  generally
> this is how linux is rolling ... include/linux//.h
> -mike
Sounds reasonable.  Let's use this going forward.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] tnetv107x cpsw ethernet switch driver

[Ben Warren]

  Hi Sandeep,

On 8/12/2010 3:51 PM, Paulraj, Sandeep wrote:
>> This patch series adds support for the cpsw ethernet switch found on
>> tnetv107x
>> and other SoCs from Texas Instruments.
>>
>> Cyril Chemparathy (2):
>>TI: netdev: add driver for cpsw ethernet device
>>TI: add tnetv107x evm board support for cpsw
>>
>>   board/ti/tnetv107xevm/sdb_board.c |  155 +++
>>   drivers/net/Makefile  |1 +
>>   drivers/net/cpsw.c|  840
>> +
>>   include/configs/tnetv107x_evm.h   |   16 +
>>   include/netdev.h  |   29 ++
>>   5 files changed, 1041 insertions(+), 0 deletions(-)
>>   create mode 100644 drivers/net/cpsw.c
>
> Ben,
>
> Can you take a look at this series?
>
I started looking at it a week ago and something came up.  My first 
impression is that the driver needs an include file.  netdev.h is 
reserved for device driver prototypes and common definitions.

I'll try to give it a thorough review soon.
> Regards,
> Sandeep
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] AT91/AVR32: at91_emac.c VS macb.c in drivers/net

[Ben Warren]

Hi Reinhard

On Tuesday, August 10, 2010, Reinhard Meyer  wrote:
> Hallo,
>
> macb.c is known to work for AT91 and AVR32.
>
> Why was at91_emac.c introduced into mainstream?
>
> By name it suggests it is designed to work with AT91 (only)?
>
> I don't think it is desireable to have to drivers doing the same task.
>
> Unless someone has a good point why we need at91_emac.c I propose to
> remove it from mainstream.
>
If they really are for the same hardware block, then I agree.  For
this, though, you'll need to get many testers and 'Acked-by's.
> Best Regards,
> Reinhard
>
Regards,
Ben

> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot patch base version

[Ben Warren]

  Hi Joe,

On 8/9/2010 5:36 PM, Joe Hershberger wrote:
> Hello,
>
> I'm looking to submit some patches that I'm currently running on
> u-boot-2009.11.  I'd like to know before I go through the trouble of
> creating the separate patches if it is a problem for the patches to be
> based on that version.  Should I first port the changes to a newer
> version or not?
>
All patches should be based on the current top-of-tree, which is 
available at:

git://git.denx.de/u-boot.git

If this advice appears to be in a foreign language, you need to read 
about git, and will find all sorts of stuff about it on the web.

> Thanks,
> -Joe
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Fix faulty definition of uec_initialize()

[Ben Warren]

  On 8/9/2010 1:18 PM, Mike Frysinger wrote:
> On Mon, Aug 9, 2010 at 3:15 PM, Joakim Tjernlund wrote:
>> The correct definition is in drivers/qe/uec.h so just
>> include that one instead.
> ... except that bleeds a ton of crap from uec.h into the global
> namespace for everyone.  better would be to move the prototype out of
> uec.h and into netdev.h and make sure uec.h includes netdev.h.
> -mike
> ___
Agreed.  Please find a way to have UEC-related stuff only on boards that 
care about it.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request - net

[Ben Warren]

Wolfgang,

The following changes since commit b417260d871d4d8d336c160d95ed40cc8c0fb0fa:
   Marek Vasut (1):
 PXA: Declare __io for vpac270 IDE

are available in the git repository at:

   git://git.denx.de/u-boot-net.git master

Ben Warren (1):
   Fix compile warnings for const correctness

Heiko Schocher (1):
   net ppc: fix ethernet device names with spaces

Kim Phillips (1):
   net: rename "FSL UECx" net interfaces "UECx"

Mike Frysinger (3):
   miiphy: constify device name
   miiphy: unify device list lookup
   miiphy: leverage current_mii cache more

Stefano Babic (1):
   net,fec: Shorten device name as done for other drivers

  README   |8 +-
  arch/arm/cpu/arm920t/at91rm9200/ether.c  |4 +-
  arch/arm/cpu/ixp/npe/include/npe.h   |4 +-
  arch/arm/cpu/ixp/npe/miiphy.c|4 +-
  arch/m68k/include/asm/fec.h  |4 +-
  arch/mips/cpu/au1x00_eth.c   |4 +-
  arch/powerpc/cpu/mpc8220/fec.c   |   10 +-
  arch/powerpc/cpu/mpc8260/ether_fcc.c |2 +-
  arch/powerpc/cpu/mpc8260/ether_scc.c |2 +-
  arch/powerpc/cpu/mpc85xx/ether_fcc.c |2 +-
  arch/powerpc/cpu/mpc8xx/fec.c|   12 +-
  arch/powerpc/cpu/mpc8xx/scc.c|2 +-
  arch/powerpc/cpu/ppc4xx/miiphy.c |4 +-
  board/evb64260/eth.c |6 +-
  board/freescale/mpc8560ads/mpc8560ads.c  |2 +-
  board/funkwerk/vovpn-gw/vovpn-gw.c   |2 +-
  board/keymile/common/keymile_hdlc_enet.c |4 +-
  board/keymile/km8xx/km8xx_hdlc_enet.c|2 +-
  board/motionpro/motionpro.c  |4 +-
  board/prodrive/p3mx/mv_eth.c |8 +-
  board/sbc8560/sbc8560.c  |2 +-
  board/stx/stxgp3/stxgp3.c|2 +-
  board/stx/stxssa/stxssa.c|2 +-
  board/stx/stxxtc/stxxtc.c|6 +-
  board/tqc/tqm8xx/tqm8xx.c|4 +-
  common/cmd_mii.c |2 +-
  common/miiphyutil.c  |  155 ++---
  doc/README.kmeter1   |2 +-
  doc/uImage.FIT/howto.txt |4 +-
  drivers/net/4xx_enet.c   |4 +-
  drivers/net/altera_tse.c |4 +-
  drivers/net/at91_emac.c  |6 +-
  drivers/net/bfin_mac.c   |4 +-
  drivers/net/davinci_emac.c   |4 +-
  drivers/net/designware.c |4 +-
  drivers/net/eepro100.c   |7 +-
  drivers/net/ep93xx_eth.c |8 +-
  drivers/net/fec_mxc.c|6 +-
  drivers/net/macb.c   |4 +-
  drivers/net/mcfmii.c |4 +-
  drivers/net/mpc512x_fec.c|   10 +-
  drivers/net/mpc5xxx_fec.c|8 +-
  drivers/net/mvgbe.c  |4 +-
  drivers/net/ns7520_eth.c |4 +-
  drivers/net/phy/miiphybb.c   |6 +-
  drivers/net/tsec.c   |8 +-
  drivers/qe/uec.c |8 +-
  drivers/qe/uec_phy.c |6 +-
  include/configs/MPC8323ERDB.h|2 +-
  include/configs/MPC832XEMDS.h|2 +-
  include/configs/MPC8360EMDS.h|2 +-
  include/configs/MPC8360ERDK.h|2 +-
  include/configs/MPC8568MDS.h |2 +-
  include/configs/MPC8569MDS.h |2 +-
  include/configs/NSCU.h   |1 -
  include/configs/TK885D.h |6 +-
  include/configs/TQM855L.h|2 +-
  include/configs/TQM855M.h|2 +-
  include/configs/TQM860L.h|2 +-
  include/configs/TQM860M.h|2 +-
  include/configs/TQM862L.h|2 +-
  include/configs/TQM862M.h|2 +-
  include/configs/TQM866M.h|2 +-
  include/configs/TQM885D.h|2 +-
  include/configs/ep82xxm.h|2 +-
  include/configs/idmr.h   |2 +-
  include/configs/keymile-common.h |4 +-
  include/configs/km8xx.h  |2 +-
  include/configs/kmeter1.h|2 +-
  include/configs/v38b.h   |2 +-
  include/miiphy.h |   30 +++---
  include/net.h|2 +-
  net/eth.c|2 +-
  73 files changed, 228 insertions(+), 233 deletions(-)


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NET: move legacy enc28j60.c to sidetrack as enc28j60_lpc2292.c

[Ben Warren]

  On 8/6/2010 7:06 AM, Reinhard Meyer (-VC) wrote:
> This patch is required before the upcoming new enc28j60 driver
> using SPI framework patch can be applied:
> - Move legacy enc28j60.c to enc28j60_lpc2292.c.
> - Change Makefile and the two affected boards' definition files.
>
> Tested with ./MAKEALL ARM7 that both boards still compile.
>
> Signed-off-by: Reinhard Meyer
> ---
>   drivers/net/Makefile|2 +-
>   drivers/net/enc28j60.c  |  982 
> --
>   drivers/net/enc28j60_lpc2292.c  |  983 
> +++
>   include/configs/SMN42.h |2 +-
>   include/configs/lpc2292sodimm.h |2 +-
>   5 files changed, 986 insertions(+), 985 deletions(-)
>   delete mode 100644 drivers/net/enc28j60.c
>   create mode 100644 drivers/net/enc28j60_lpc2292.c
Please use 'git mv' followed by 'git format-patch -C' when moving 
files.  It's much easier to review.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Ben Warren]

  Hi Wolfgang,

On 8/2/2010 2:08 PM, Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message<4c570eee.8060...@gmail.com>  you wrote:
>>> And the merge window is closed.
>>>
>> What day should we consider the window to have closed?  You website says
>> July 17, but that seems an awfully long time ago and I think a lot of
>> code has been accepted since then, right?
> Oops. I was so busy in the last few weeks that I missed to formally
> announce the new status. Sorry for that.
>
That's OK, it just snuck up on me.  I have a few things I was hoping to 
get it, but they can wait until the next window I guess.
> Will update ASAP.
>
> Best regards,
>
> Wolfgang Denk
>
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Ben Warren]

  Hi Wolfgang,

On 8/2/2010 7:57 AM, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message  you 
> wrote:
>> I have a patch that enables audio on the 1022, can you pick up that one too ?
> This is not exactly a bug fix, right?
>
> And the merge window is closed.
>
What day should we consider the window to have closed?  You website says 
July 17, but that seems an awfully long time ago and I think a lot of 
code has been accepted since then, right?
> Best regards,
>
> Wolfgang Denk
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Fix compile warnings for const correctness

[Ben Warren]

Commit 6e37b1a3a25004d3df5867de49fff6b3fc9c4f04 modifies several net calls
to take a (const char *) parameter instead of (char *), but in some cases
the modified functions call other functions taking (char *).  The end result
is warnings about discarding the const qualifier.

This patch fixes these other function signatures.

Signed-off-by: Ben Warren 
---
 drivers/net/at91_emac.c|2 +-
 drivers/net/eepro100.c |3 ++-
 drivers/net/phy/miiphybb.c |6 +++---
 include/net.h  |2 +-
 net/eth.c  |2 +-
 5 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
index 0912f52..d82459b 100644
--- a/drivers/net/at91_emac.c
+++ b/drivers/net/at91_emac.c
@@ -162,7 +162,7 @@ int  at91emac_write(at91_emac_t *at91mac, unsigned char 
addr,
 
 #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
 
-at91_emac_t *get_emacbase_by_name(char *devname)
+at91_emac_t *get_emacbase_by_name(const char *devname)
 {
struct eth_device *netdev;
 
diff --git a/drivers/net/eepro100.c b/drivers/net/eepro100.c
index 5cb767a..22e14e3 100644
--- a/drivers/net/eepro100.c
+++ b/drivers/net/eepro100.c
@@ -321,7 +321,8 @@ static int set_phyreg (struct eth_device *dev, unsigned 
char addr,
 /* Check if given phyaddr is valid, i.e. there is a PHY connected.
  * Do this by checking model value field from ID2 register.
  */
-static struct eth_device* verify_phyaddr (char *devname, unsigned char addr)
+static struct eth_device* verify_phyaddr (const char *devname,
+   unsigned char addr)
 {
struct eth_device *dev;
unsigned short value;
diff --git a/drivers/net/phy/miiphybb.c b/drivers/net/phy/miiphybb.c
index 2768c75..1045cf1 100644
--- a/drivers/net/phy/miiphybb.c
+++ b/drivers/net/phy/miiphybb.c
@@ -143,7 +143,7 @@ void bb_miiphy_init(void)
}
 }
 
-static inline struct bb_miiphy_bus *bb_miiphy_getbus(char *devname)
+static inline struct bb_miiphy_bus *bb_miiphy_getbus(const char *devname)
 {
 #ifdef CONFIG_BITBANGMII_MULTI
int i;
@@ -246,7 +246,7 @@ static void miiphy_pre(struct bb_miiphy_bus *bus, char read,
  * Returns:
  *   0 on success
  */
-int bb_miiphy_read(char *devname, unsigned char addr,
+int bb_miiphy_read(const char *devname, unsigned char addr,
   unsigned char reg, unsigned short *value)
 {
short rdreg; /* register working value */
@@ -327,7 +327,7 @@ int bb_miiphy_read(char *devname, unsigned char addr,
  * Returns:
  *   0 on success
  */
-int bb_miiphy_write (char *devname, unsigned char addr,
+int bb_miiphy_write (const char *devname, unsigned char addr,
 unsigned char reg, unsigned short value)
 {
struct bb_miiphy_bus *bus;
diff --git a/include/net.h b/include/net.h
index a180881..ab571eb 100644
--- a/include/net.h
+++ b/include/net.h
@@ -117,7 +117,7 @@ extern void eth_try_another(int first_restart); /* 
Change the device */
 extern void eth_set_current(void); /* set nterface to ethcur var */
 #endif
 extern struct eth_device *eth_get_dev(void);   /* get the current device MAC */
-extern struct eth_device *eth_get_dev_by_name(char *devname); /* get device */
+extern struct eth_device *eth_get_dev_by_name(const char *devname);
 extern struct eth_device *eth_get_dev_by_index(int index); /* get dev @ index 
*/
 extern int eth_get_dev_index (void);   /* get the device index */
 extern void eth_parse_enetaddr(const char *addr, uchar *enetaddr);
diff --git a/net/eth.c b/net/eth.c
index de6d5c6..993306f 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -102,7 +102,7 @@ struct eth_device *eth_get_dev(void)
return eth_current;
 }
 
-struct eth_device *eth_get_dev_by_name(char *devname)
+struct eth_device *eth_get_dev_by_name(const char *devname)
 {
struct eth_device *dev, *target_dev;
 
-- 
1.6.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] miiphy: constify device name

[Ben Warren]

  Hi Mike,

On 7/27/2010 3:35 PM, Mike Frysinger wrote:
> The driver name does not need to be writable, so constify it.
>
> Signed-off-by: Mike Frysinger
> ---
>   arch/arm/cpu/arm920t/at91rm9200/ether.c |4 +-
>   arch/arm/cpu/ixp/npe/include/npe.h  |4 +-
>   arch/arm/cpu/ixp/npe/miiphy.c   |4 +-
>   arch/m68k/include/asm/fec.h |4 +-
>   arch/mips/cpu/au1x00_eth.c  |4 +-
>   arch/powerpc/cpu/mpc8220/fec.c  |8 +++---
>   arch/powerpc/cpu/mpc8xx/fec.c   |8 +++---
>   arch/powerpc/cpu/ppc4xx/miiphy.c|4 +-
>   board/evb64260/eth.c|6 ++--
>   board/prodrive/p3mx/mv_eth.c|8 +++---
>   common/cmd_mii.c|2 +-
>   common/miiphyutil.c |   41 
> ---
>   drivers/net/4xx_enet.c  |4 +-
>   drivers/net/altera_tse.c|4 +-
>   drivers/net/at91_emac.c |4 +-
>   drivers/net/bfin_mac.c  |4 +-
>   drivers/net/davinci_emac.c  |4 +-
>   drivers/net/designware.c|4 +-
>   drivers/net/eepro100.c  |4 +-
>   drivers/net/ep93xx_eth.c|8 +++---
>   drivers/net/fec_mxc.c   |4 +-
>   drivers/net/macb.c  |4 +-
>   drivers/net/mcfmii.c|4 +-
>   drivers/net/mpc512x_fec.c   |8 +++---
>   drivers/net/mpc5xxx_fec.c   |8 +++---
>   drivers/net/mvgbe.c |4 +-
>   drivers/net/ns7520_eth.c|4 +-
>   drivers/net/tsec.c  |8 +++---
>   drivers/qe/uec.c|6 ++--
>   include/miiphy.h|   30 +++---
>   30 files changed, 107 insertions(+), 106 deletions(-)
As usually happens when going for const-correctness, it becomes an 
exercise in peeling back the layers of compile warnings.  When I run 
MAKEALL ppc, I get all sorts of 'discards qualifier' warnings.  Anyway, 
I think they're fixed and as soon as MAKEALL finishes running I'll post 
a follow-on patch.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: rename "FSL UECx" net interfaces "UECx"

[Ben Warren]

  Hi Kim,

On 7/26/2010 4:34 PM, Kim Phillips wrote:
> continuation of commit 2ecc2262d66a286e3aac79005bcb5f461312dea8
> "net ppc: fix ethernet device names with spaces" (currently in
> u-boot-net.git) for QE based parts.
>
> Signed-off-by: Kim Phillips
> ---
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] drivers/net/enc28j60.c - generalisation, how?

[Ben Warren]

On Sunday, July 25, 2010, Reinhard Meyer
 wrote:
> Mike Frysinger wrote:
>
> On Sunday, July 25, 2010 20:07:31 Reinhard Meyer wrote:
>
>
> I can rename the current driver to like "enc28j60_lpc2292.c" and make the
> two affected boards use it, so they still compile and work. I can't do
> those boards' maintainers work and add the required code to use the new
> driver and make a generic spi framework for the lpc2292. They currently
> use a very private spi approach.
> Or I call the new driver something like "enc28j60_generic.c".
> I am definitely not going to port the existing two lpc2292 boards to use
> the new enc28j60 driver.
>
>
>
> i prefer the former
>
>
> I agree. So a first patch would be the renaming, editing the affected boards 
> *.h and the Makefile in drivers/net:
> COBJS-$(CONFIG_ENC28J60) += enc28j60.o
> to
> COBJS-$(CONFIG_ENC28J60_LPC2292) += enc28j60_lpc2292.o
>
> In the same patch extract the 200 or so defines for the chip to enc28j60.h 
> (to be used by both drivers).
>
> One issue remains: the old driver has a lot of coding style violations, I can 
> fix them, but see no point in that. The new driver will have them fixed.
>
> But before I proceed I need Bens OK to go that way:)
>
> Reinhard
>
Sounds good.  Go for it.

Regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] drivers/net/enc28j60.c - generalisation, how?

[Ben Warren]

Hi Reinhard,

On Sun, Jul 25, 2010 at 1:06 PM, Reinhard Meyer <
reinhard.me...@emk-elektronik.de> wrote:

> Mike Frysinger wrote:
> > On Saturday, July 24, 2010 02:11:16 Reinhard Meyer wrote:
> >
> >> I would like to generalize that driver and make it also
> >> CONFIG_NET_MULTI-able.
> >>
> >
> > someone already has ... look at the archives in december of 09
> >
> Thanks for the hint Mike,
> it seems the thread there has died, and the work left incomplete however.
> But it gives a head start to complete it.
> The main issue I had is already proposed in that thread: rename the old
> driver and make a new one :)
>
Then that seems like the right approach.  Create the new driver, port the
existing boards to use it and see if anybody cares.  If somebody responds,
you've found a tester.  If not, there may be some boards in the tree that
compile fine but don't run.  Not a problem I'd lose much sleep over.

> Reinhard
>
Thanks for the effort!
--Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net, fec: Shorten device name as done for other drivers

[Ben Warren]

  Hi Stefano,

n 7/19/2010 10:57 PM, Stefano Babic wrote:
> After discussion on the ML it is suggested to drop unrequired
> and not useful characters from the device name.
> This patch changes the name for the fec_mxc driver from
> "FEC_MXC" to "FEC".
>
> Signed-off-by: Stefano Babic
> ---
>   drivers/net/fec_mxc.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
> index 57f89a3..6b801ce 100644
> --- a/drivers/net/fec_mxc.c
> +++ b/drivers/net/fec_mxc.c
> @@ -743,7 +743,7 @@ static int fec_probe(bd_t *bd)
>   writel(0x05ee0024,&fec->eth->r_cntrl);  /* FIXME 0x05ee0004 */
>   fec_mii_setspeed(fec);
>
> - sprintf(edev->name, "FEC_MXC");
> + sprintf(edev->name, "FEC");
>
>   miiphy_register(edev->name, fec_miiphy_read, fec_miiphy_write);
>
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] net ppc: fix ethernet device names with spaces

[Ben Warren]

  Hi Heiko,

On 7/20/2010 8:45 AM, Heiko Schocher wrote:
> since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names
> with spaces drop a
>
> Warning: eth device name has a space!
>
> message. This patch fix it for:
>
> - "FEC ETHERNET" devices found on
>mpc512x, mpc5xxx, mpc8xx and mpc8220 boards.
>renamed to "FEC".
> - "SCC ETHERNET" devices found on
>mpc8xx, mpc82xx based boards. Renamed to "SCC".
> - "HDLC ETHERNET" devices found on mpc8xx boards
>Renamed to "HDLC"
> - "FCC ETHERNET" devices found on mpc8260 and mpc85xx based
>boards. Renamed to "FCC"
>
> Tested on the kup4k board.
>
> Signed-off-by: Heiko Schocher
>
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] net, fec: fix "Warning: eth device name has a space!" for FEC devices

[Ben Warren]

  Hi Heiko,

On 7/19/2010 3:57 PM, Wolfgang Denk wrote:
> Dear Heiko Schocher,
>
> In message<4c44c8f9.6020...@denx.de>  you wrote:
>> since commit 1384f3bb8a4f9066805b70c1418eda78ecb73fdd ethernet names
>> with spaces drop a
>>
>> Warning: eth device name has a space!
>>
>> message. This patch fix it for:
>>
>> - "FEC ETHERNET" devices found on
>>mpc512x, mpc5xxx, mpc8xx and mpc8220 boards.
>>renamed to "FEC".
>> - "SCC ETHERNET" devices found on
>>mpc8xx, mpc82xx based boards. Renamed to "SCC".
>> - "HDLC ETHERNET" devices found on mpc8xx boards
>>Renamed to "HDLC"
>> - "FCC ETHERNET" devices found on mpc8260 and mpc85xx based
>>boards. Renamed to "FCC"
> The Subject: (which is way too long, btw.) does not match the content
> of this patch.
>
>
> I'm not sure if it is a good idea to change the board specific
> README's. For example, board/LEOX/elpt860/README.LEOX shows
>
>   U-Boot 0.2.2 ...
>   ...
>   Net:   SCC ETHERNET
>
> For this specific version, the string was correct. Changing it is
> technically not correct.
>
> Best regards,
>
> Wolfgang Denk
>
I just ran MAKEALL on this and it's clean, so if you address Wolfgang's 
concerns we'll pull it in.

regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net, fec: fix "Warning: eth device name has a space!" for FEC devices

[Ben Warren]

  Hi Stefano,

On 7/19/2010 12:11 PM, Stefano Babic wrote:
> Wolfgang Denk wrote:
>
>> I always wondered why we need such a long (and slow to type) name. I
>> suggest we use this opportunity and change the name into a plain and
>> simple "FEC" resp. "SCC" and "FCC" ?
> Then probably unify the rule even for other architectures. We have a
> "FEC_MXC", too, for Freescale's i.MX processors. We can use "FEC_PPC",
> "SCC_PPC" if we want to add the architecture name (I do not think is
> useful), or better set the name to "FEC" for fec_mxc.c, too.
>
> Best regards,
> Stefano Babic
>
Unless you have a chip with both MXC and PPC FECs, which I doubt, I 
don't think the extra namespace buys anything.  Saving a few keystrokes, 
on the other hand (no pun intended) is a good thing.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 0/4] Marvell GbE multiple SoC support

[Ben Warren]

  Hi Albert,

On 7/12/2010 1:24 PM, Albert Aribaud wrote:
> NOTES
>
> 1) This patchset will only apply above a previously posted and
> Acked-by patch available on the mailing list archives e.g. at:
> 
> ("kirkwood_egiga: updates: fix DRAM mapping and typo").
>
> 2) This patchset will build for edminiv2 but requires a bugfix
> patch, also Acked-by and available on archives as well at e.g.
> 
> ("kirkwood_egiga: bugfix: add DMA sequence points").
>
> 3) This patchset will only apply above a previously posted, not
> yet Acked-by patch available on the mailing list archives e.g. at:
> 
> ("kirkwood_egiga: CONFIG_SKIP_LOCAL_MAC_RANDOMIZATION").
>
> PATCHSET HISTORY
>
> V1:   First submission.
> V2:   Reorganization as per Prafulla Wadasakar's suggestion.
>   Used -C in format-patch to render renames correctly.
>   Removal of DRAM patch posted standalone.
>   Removal of unrelated changes.
> V3:   Removal of DMA bugfix patch posted standalone
>   Introduced MAC non-randomization config option
>   Added short description to each patch.
> V4:   Renaming of mv_egiga to mvgbe throughout.
>   Removal of MAC non-randomization patch posted standalone.
>   Removal of unrelated edminiv2 changes.
>   Move of MAX_MVGBE_DEVS from driver to SoC files.
Patchset v4 has been applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request - net *updated*

[Ben Warren]

Wolfgang,

The following changes since commit 54841ab50c20d6fa6c9cc3eb826989da3a22d934:
   Wolfgang Denk (1):
 Make sure that argv[] argument pointers are not modified.

are available in the git repository at:

   git://git.denx.de/u-boot-net.git master

Albert Aribaud (7):
   kirkwood_egiga: bugfix: add DMA sequence points
   kirkwood_egiga: updates: fix DRAM mapping and typo
   kirkwood_egiga: CONFIG_SKIP_LOCAL_MAC_RANDOMIZATION
   net: rename: kirkwood_egiga as mvgbe
   mvgbe: support SoCs other than kirkwood
   mvgbe: add support for orion5x GbE controller
   edminiv2: add ethernet support

Ben Warren (1):
   Write MAC address automatically on MACB-based boards

Eric Bénard (2):
   at91_emac: Write MAC address automatically
   cpuat91: unbreak ethernet

Heiko Schocher (1):
   tsec: add micrel ksz804 phy

Hoan Hoang (3):
   AX88180: fix media typos
   AX88180: add support for the Marvell 88E1118 phy
   AX88180: make OUTW handle 32bit/16bit defines too

Juergen Kilb (1):
   smc91xx_eeprom: Correct chip detection check.

Mike Frysinger (7):
   net: dm9000x: re-add casts to I/O pointers to fix gcc warnings
   AX88180: add missing init prototype
   AX88180: improve phy searching
   AX88180: switch to common mii.h header
   net: warn about spaces in device names
   uli526x: drop newlines from device name
   AX88180: use standard I/O accessors

Stefan Roese (1):
   net: Add option to disable fiber on M88E PHY for PPC4xx

Timur Tabi (1):
   tsec: fix the return value for tsec_eth_init()

Vipin KUMAR (1):
   SPEAr : Network driver support added

  arch/arm/cpu/arm926ejs/kirkwood/cpu.c   |4 +-
  arch/arm/cpu/arm926ejs/orion5x/cpu.c|8 +
  arch/arm/include/asm/arch-kirkwood/kirkwood.h   |5 +
  arch/arm/include/asm/arch-orion5x/orion5x.h |4 +
  board/LaCie/edminiv2/edminiv2.c |   36 ++
  board/LaCie/edminiv2/edminiv2.h |   41 ++
  board/afeb9260/afeb9260.c   |7 -
  board/atmel/at91cap9adk/at91cap9adk.c   |7 -
  board/atmel/at91sam9260ek/at91sam9260ek.c   |7 -
  board/atmel/at91sam9263ek/at91sam9263ek.c   |7 -
  board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c |7 -
  board/calao/sbc35_a9g20/sbc35_a9g20.c   |7 -
  board/eukrea/cpu9260/cpu9260.c  |7 -
  board/ronetix/pm9263/pm9263.c   |7 -
  doc/README.designware_eth   |   25 +
  drivers/net/4xx_enet.c  |5 +
  drivers/net/Makefile|3 +-
  drivers/net/at91_emac.c |   60 ++-
  drivers/net/ax88180.c   |  137 ---
  drivers/net/ax88180.h   |  104 ++---
  drivers/net/designware.c|  531 +++
  drivers/net/designware.h|  264 +++
  drivers/net/dm9000x.c   |   12 +-
  drivers/net/kirkwood_egiga.h|  505 -
  drivers/net/macb.c  |   23 +-
  drivers/net/{kirkwood_egiga.c =>  mvgbe.c}   |  377 +
  drivers/net/mvgbe.h |  505 +
  drivers/net/tsec.c  |   37 ++-
  drivers/net/uli526x.c   |2 +-
  examples/standalone/smc911x_eeprom.c|2 +-
  include/configs/cpuat91.h   |9 +-
  include/configs/edminiv2.h  |   19 +-
  include/configs/guruplug.h  |4 +-
  include/configs/km_arm.h|4 +-
  include/configs/mv88f6281gtw_ge.h   |4 +-
  include/configs/openrd_base.h   |4 +-
  include/configs/rd6281a.h   |4 +-
  include/configs/sheevaplug.h|4 +-
  include/netdev.h|4 +-
  net/eth.c   |3 +
  40 files changed, 1898 insertions(+), 907 deletions(-)
  create mode 100644 board/LaCie/edminiv2/edminiv2.h
  create mode 100644 doc/README.designware_eth
  create mode 100644 drivers/net/designware.c
  create mode 100644 drivers/net/designware.h
  delete mode 100644 drivers/net/kirkwood_egiga.h
  rename drivers/net/{kirkwood_egiga.c =>  mvgbe.c} (60%)
  create mode 100644 drivers/net/mvgbe.h


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/5] mv_egiga: support SoCs other than kirkwood

[Ben Warren]

Hi Albert,

On Mon, Jul 12, 2010 at 1:56 AM, Albert ARIBAUD wrote:

> Le 12/07/2010 07:49, Prafulla Wadaskar a écrit :
> >
> >
> >> -Original Message-
> >> From: u-boot-boun...@lists.denx.de
> >> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> >> Sent: Sunday, July 11, 2010 1:32 PM
> >> To: u-boot@lists.denx.de
> >> Subject: [U-Boot] [PATCH V3 2/5] mv_egiga: support SoCs other
> >> than kirkwood
> >>
> >> Rename all references to kirkwood in mv_egiga symbols
> >> throughout the whole codebase.
> >>
> >> Signed-off-by: Albert Aribaud
> >> ---
> >
> > Pls break this patch as-
> >>   arch/arm/cpu/arm926ejs/kirkwood/cpu.c |4 +-
> >>   arch/arm/include/asm/arch-kirkwood/kirkwood.h |5 +
> > Kirkwood SOC specific
> >
> >>   drivers/net/Makefile  |2 +-
> >>   drivers/net/mv_egiga.c|  322
> >> +-
> >>   drivers/net/mv_egiga.h|  466
> >>   include/netdev.h  |2 +-
> > Net: driver specific for net repo
> >
> >> 
> >>   include/configs/guruplug.h|4 +-
> >>   include/configs/km_arm.h  |4 +-
> >>   include/configs/mv88f6281gtw_ge.h |4 +-
> >>   include/configs/openrd_base.h |4 +-
> >>   include/configs/rd6281a.h |4 +-
> >>   include/configs/sheevaplug.h  |4 +-
> >
> > Board updates
> > In the same order, so that it is easier to pick them separately by net
> and Marvell repos.
> >
> > Regards..
> > Prafulla . .
>
> If I split this patch, it will not build correctly any more.
>
> Usually, these should be split up.  In this case, the dependencies are
significant, so just leave it as-is.  If Prafulla ACKs, I'll pull the whole
group into the net repo.

> Amicalement,
> --
> Albert.
>
regards,
Ben

> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/5] mv_egiga: support SoCs other than kirkwood

[Ben Warren]

Hi Albert,

On Mon, Jul 12, 2010 at 1:53 AM, Albert ARIBAUD wrote:

> Le 12/07/2010 08:53, Prafulla Wadaskar a écrit :
>
>> -   struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
>
> -   struct kwgbe_registers *regs = dkwgbe->regs;
> +   struct mv_egiga_device *dmvegiga = to_mv_egiga(dev);
> +   struct mv_egiga_registers *regs = dmvegiga->regs;
>
 I suggest to keep name as mvgbe here instead of mv_egiga, 3

>>> additional chars, increases overall code size
>>> huh?  The name is consistent with the rest of his work, and *if* the
>>> code really increases in size, I can't imagine that 3 chars really
>>> matters...
>>>
>>
>> That's true.
>> But if we can do it why to avoid it? again it helps to keep same
>> indentation (keeping them below 80char size)
>>
>
> I don't think I changed indentation here, and the issue is about line
> lengths, right?
>
> Initially I chose mv egiga because the file names used egiga while the code
> used gbe, and I wanted clarity, so I decided to keep only one of egiga and
> gbe. Now which one I should keep is not really important to me, and a Google
> search for marvell egiga vs marvell gbe indicates gbe appears much more
> frequently, so someone looking into this will probably know "GbE" more than
> "egiga".
>
> I suggest that:
>
> - I switch the file names from mv_egiga to "mvgbe" (to be consistent with
> Prafulla's comment on mv_sata becoming mvsata), and
>
> - I replace mv_egiga/MV_EGIGA symbols with mvgbe/MVGBE.
>
> That will retain (as much) clarity and uniformity (as egiga does), which is
> what I think Ben is looking for, and it'll keep name length at a minimum,
> which should satisfy Prafulla.
>
> Ben, Prafulla (and others as well, of course), do you agree?
>
OK with me.

>

Amicalement,
> --
> Albert.
>
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request - net

[Ben Warren]

Wolfgang,

The following changes since commit 54841ab50c20d6fa6c9cc3eb826989da3a22d934:
   Wolfgang Denk (1):
 Make sure that argv[] argument pointers are not modified.

are available in the git repository at:

   git://git.denx.de/u-boot-net.git master

Albert Aribaud (2):
   kirkwood_egiga: bugfix: add DMA sequence points
   kirkwood_egiga: updates: fix DRAM mapping and typo

Ben Warren (1):
   Write MAC address automatically on MACB-based boards

Eric Bénard (2):
   at91_emac: Write MAC address automatically
   cpuat91: unbreak ethernet

Heiko Schocher (1):
   tsec: add micrel ksz804 phy

Hoan Hoang (3):
   AX88180: fix media typos
   AX88180: add support for the Marvell 88E1118 phy
   AX88180: make OUTW handle 32bit/16bit defines too

Juergen Kilb (1):
   smc91xx_eeprom: Correct chip detection check.

Mike Frysinger (7):
   net: dm9000x: re-add casts to I/O pointers to fix gcc warnings
   AX88180: add missing init prototype
   AX88180: improve phy searching
   AX88180: switch to common mii.h header
   net: warn about spaces in device names
   uli526x: drop newlines from device name
   AX88180: use standard I/O accessors

Stefan Roese (1):
   net: Add option to disable fiber on M88E PHY for PPC4xx

Timur Tabi (1):
   tsec: fix the return value for tsec_eth_init()

Vipin KUMAR (1):
   SPEAr : Network driver support added

  board/afeb9260/afeb9260.c   |7 -
  board/atmel/at91cap9adk/at91cap9adk.c   |7 -
  board/atmel/at91sam9260ek/at91sam9260ek.c   |7 -
  board/atmel/at91sam9263ek/at91sam9263ek.c   |7 -
  board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c |7 -
  board/calao/sbc35_a9g20/sbc35_a9g20.c   |7 -
  board/eukrea/cpu9260/cpu9260.c  |7 -
  board/ronetix/pm9263/pm9263.c   |7 -
  doc/README.designware_eth   |   25 +
  drivers/net/4xx_enet.c  |5 +
  drivers/net/Makefile|1 +
  drivers/net/at91_emac.c |   60 ++-
  drivers/net/ax88180.c   |  137 ---
  drivers/net/ax88180.h   |  104 ++---
  drivers/net/designware.c|  531 +++
  drivers/net/designware.h|  264 +++
  drivers/net/dm9000x.c   |   12 +-
  drivers/net/kirkwood_egiga.c|   19 +-
  drivers/net/macb.c  |   23 +-
  drivers/net/tsec.c  |   37 ++-
  drivers/net/uli526x.c   |2 +-
  examples/standalone/smc911x_eeprom.c|2 +-
  include/configs/cpuat91.h   |9 +-
  include/netdev.h|2 +
  net/eth.c   |3 +
  25 files changed, 1075 insertions(+), 217 deletions(-)
  create mode 100644 doc/README.designware_eth
  create mode 100644 drivers/net/designware.c
  create mode 100644 drivers/net/designware.h


regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] kirkwood_egiga: updates: fix DRAM mapping and typo

[Ben Warren]

  Hi Albert,

On 7/5/2010 11:15 AM, Albert Aribaud wrote:
> DRAM window mapping uses kirkwood-provided functions instead
> of global gd as do other drivers--fix this.
>
> Also, fix a typo in a comment
>
> Signed-off-by: Albert Aribaud
> ---
>   drivers/net/kirkwood_egiga.c |   10 ++
>   1 files changed, 6 insertions(+), 4 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 06/18] SPEAr : Network driver support added

[Ben Warren]

  Hi Vipin,

On 6/28/2010 10:23 PM, Vipin KUMAR wrote:
> From: Vipin KUMAR
>
> Designware network driver support added.
> This is a Synopsys ethernet controller
>
> Signed-off-by: Vipin Kumar
> ---
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] kirkwood_egiga: bugfix: add DMA sequence points

[Ben Warren]

  Hi Albert,

On 7/10/2010 6:41 AM, Albert Aribaud wrote:
> Insert isb() sequence points to ensure DMA descriptors
> are filled in and set up before actual DMA occurs.
>
> Signed-off-by: Albert Aribaud
> ---
> PATCHSET HISTORY
>
> V1: initial submit
> V2: fixed badly placed isb()
>
>   drivers/net/kirkwood_egiga.c |9 -
>   1 files changed, 8 insertions(+), 1 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 14/35] Blackfin: bfin_mac: convert to portmux framework

[Ben Warren]

  Hi Mike,

On 7/11/2010 11:52 PM, Ben Warren wrote:
>  Hi Mike,
>
> On 7/5/2010 2:30 AM, Mike Frysinger wrote:
>> Rather than bang MMRs directly, use the new portmux framework to handle
>> the details.  While we're doing this, let boards declare the exact list
>> of pins they need in case there is one or two they don't actually have
>> hooked up.
>>
>> Signed-off-by: Mike Frysinger
>> ---
>>   drivers/net/bfin_mac.c |   47 
>> +++
>>   1 files changed, 11 insertions(+), 36 deletions(-)
> Applied to net repo.
>
> thanks,
> Ben
Instead, please keep together with all the others, and add this:

Acked-by: Ben Warren

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net, tsec: add micrel ksz804 phy

[Ben Warren]

  Hi Heiko,

On 7/5/2010 3:23 AM, Heiko Schocher wrote:
> net, tsec: add micrel ksz804 phy
>
> Signed-off-by: Heiko Schocher
> ---
>   drivers/net/tsec.c |   22 ++
>   1 files changed, 22 insertions(+), 0 deletions(-)
Applied to net repo, after cleaning up patch title.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 24/35] Blackfin: bf518f-ezbrd: handle different PHYs dynamically

[Ben Warren]

  On 7/11/2010 11:53 PM, Ben Warren wrote:
>  Hi Mike,
>
> On 7/5/2010 2:30 AM, Mike Frysinger wrote:
>> The original BF518F-EZBRD's have a Micrel KSZ8893 DSA on them, but newer
>> ones only have a National PHY (which lack a RX Error interrupt 
>> line).  So
>> in the board eth init code, dynamically detect what is hooked up to 
>> the MAC
>> and handle each accordingly.
>>
>> Signed-off-by: Mike Frysinger
>> ---
>>   board/bf518f-ezbrd/bf518f-ezbrd.c |   23 +--
>>   include/configs/bf518f-ezbrd.h|   20 
>>   2 files changed, 33 insertions(+), 10 deletions(-)
> Applied to net repo.
>
> thanks,
> Ben
On second thought, it probably makes more sense to keep this as part of 
your patchset.  I shouldn't have pulled it in the first place since it's 
really board code.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 24/35] Blackfin: bf518f-ezbrd: handle different PHYs dynamically

[Ben Warren]

  Hi Mike,

On 7/5/2010 2:30 AM, Mike Frysinger wrote:
> The original BF518F-EZBRD's have a Micrel KSZ8893 DSA on them, but newer
> ones only have a National PHY (which lack a RX Error interrupt line).  So
> in the board eth init code, dynamically detect what is hooked up to the MAC
> and handle each accordingly.
>
> Signed-off-by: Mike Frysinger
> ---
>   board/bf518f-ezbrd/bf518f-ezbrd.c |   23 +--
>   include/configs/bf518f-ezbrd.h|   20 
>   2 files changed, 33 insertions(+), 10 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 14/35] Blackfin: bfin_mac: convert to portmux framework

[Ben Warren]

  Hi Mike,

On 7/5/2010 2:30 AM, Mike Frysinger wrote:
> Rather than bang MMRs directly, use the new portmux framework to handle
> the details.  While we're doing this, let boards declare the exact list
> of pins they need in case there is one or two they don't actually have
> hooked up.
>
> Signed-off-by: Mike Frysinger
> ---
>   drivers/net/bfin_mac.c |   47 
> +++
>   1 files changed, 11 insertions(+), 36 deletions(-)
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: dm9000x: re-add casts to I/O pointers to fix gcc warnings

[Ben Warren]

  Hi Mike,

On 7/4/2010 11:29 PM, Mike Frysinger wrote:
> The DM9000 in/out helper functions were casting the register address when
> it was accessing things directly (pre commit a45dde2293c816138e53c).  But
> when it was changed to using the in/out helpers, those casts were dropped
> because those functions don't take pointers.  Even more recently, those
> functions were then changed to use the read/write helpers, but the casts
> were not re-added.  This is necessary because the read/write helpers do
> take pointers.  Otherwise we get a lot of warnings like:
> dm9000x.c: In function 'dm9000_inblk_8bit':
> dm9000x.c:172: warning: passing argument 1 of 'readb'
>   makes pointer from integer without a cast
>
> Signed-off-by: Mike Frysinger
> ---
>   drivers/net/dm9000x.c |   12 ++--
>   1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
> index 137e41f..709f67a 100644
> --- a/drivers/net/dm9000x.c
> +++ b/drivers/net/dm9000x.c
> @@ -117,12 +117,12 @@ static void DM9000_iow(int reg, u8 value);
>
>   /* DM9000 network board routine  */
>
> -#define DM9000_outb(d,r) writeb(d, r)
> -#define DM9000_outw(d,r) writew(d, r)
> -#define DM9000_outl(d,r) writel(d, r)
> -#define DM9000_inb(r) readb(r)
> -#define DM9000_inw(r) readw(r)
> -#define DM9000_inl(r) readl(r)
> +#define DM9000_outb(d,r) writeb(d, (volatile u8 *)(r))
> +#define DM9000_outw(d,r) writew(d, (volatile u16 *)(r))
> +#define DM9000_outl(d,r) writel(d, (volatile u32 *)(r))
> +#define DM9000_inb(r) readb((volatile u8 *)(r))
> +#define DM9000_inw(r) readw((volatile u16 *)(r))
> +#define DM9000_inl(r) readl((volatile u32 *)(r))
>
>   #ifdef CONFIG_DM9000_DEBUG
>   static void
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] net: Add option to disable fiber on M88E1111 PHY for PPC4xx

[Ben Warren]

  Hi Stefen,

On 6/29/2010 12:23 AM, Stefan Roese wrote:
> By defining CONFIG_M88E_DISABLE_FIBER boards can configure the
> M88E PYH to disable fiber. This is needed for an upcoming PPC460GT
> based board, which has fiber/copper auto-selection enabled by default.
> This doesn't seem to work. So we disable fiber in the PHY register.
>
> Signed-off-by: Stefan Roese
> Cc: Ben Warren
> ---
> v2: - Fixed spelling: fibre ->  fiber
>
>   drivers/net/4xx_enet.c |5 +
>   1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c
> index 2fac641..144b851 100644
> --- a/drivers/net/4xx_enet.c
> +++ b/drivers/net/4xx_enet.c
> @@ -1095,6 +1095,11 @@ static int ppc_4xx_eth_init (struct eth_device *dev, 
> bd_t * bis)
>   miiphy_write (dev->name, reg, 0x18, 0x4101);
>   miiphy_write (dev->name, reg, 0x09, 0x0e00);
>   miiphy_write (dev->name, reg, 0x04, 0x01e1);
> +#if defined(CONFIG_M88E_DISABLE_FIBER)
> + miiphy_read(dev->name, reg, 0x1b,®_short);
> + reg_short |= 0x8000;
> + miiphy_write(dev->name, reg, 0x1b, reg_short);
> +#endif
>   #endif
>   #if defined(CONFIG_M88E1112_PHY)
>   if (bis->bi_phymode[devnum] == BI_PHYMODE_SGMII) {
Applied to net repo.

thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 5/5] edminiv2: add ethernet support

[Ben Warren]

  Hi Albert,

On 7/11/2010 11:14 PM, Albert ARIBAUD wrote:
> Hi Prafulla,
>
> Le 12/07/2010 08:00, Prafulla Wadaskar a écrit :
>
>>> +/*
>>> + * Ethernet
>>> +  */
>> Pls remove additional space char here
> Done.
>
>>> +#define CONFIG_MV_EGIGA/* Enable Marvell egiga
>>> [...]
>>> +#define CONFIG_RESET_PHY_R /* use reset_phy() to init
>>> mv8831116 PHY */
>> Shift above definition below (inside #ifdef CONFIG_CMD_NET), that makes more 
>> sense
> Done--actually replaced "Ethernet" with "Network" in block comment as
> the whole block is not only about Eth.
>
> Thanks for the feedback.
>
> Any remaining comments on patches 1-4?
>
> Amicalement,
That should be it.  Please post updates as needed.

regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 2/5] mv_egiga: support SoCs other than kirkwood

[Ben Warren]

  On 7/11/2010 10:45 PM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de
>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
>> Sent: Sunday, July 11, 2010 1:32 PM
>> To: u-boot@lists.denx.de
>> Subject: [U-Boot] [PATCH V3 2/5] mv_egiga: support SoCs other
>> than kirkwood
>>
>> Rename all references to kirkwood in mv_egiga symbols
>> throughout the whole codebase.
>>
>> Signed-off-by: Albert Aribaud
>> ---
>>   arch/arm/cpu/arm926ejs/kirkwood/cpu.c |4 +-
>>   arch/arm/include/asm/arch-kirkwood/kirkwood.h |5 +
>>   drivers/net/Makefile  |2 +-
>>   drivers/net/mv_egiga.c|  322
>> +-
>>   drivers/net/mv_egiga.h|  466
>> 
>>   include/configs/guruplug.h|4 +-
>>   include/configs/km_arm.h  |4 +-
>>   include/configs/mv88f6281gtw_ge.h |4 +-
>>   include/configs/openrd_base.h |4 +-
>>   include/configs/rd6281a.h |4 +-
>>   include/configs/sheevaplug.h  |4 +-
>>   include/netdev.h  |2 +-
>>   12 files changed, 418 insertions(+), 407 deletions(-)
>>
>> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
>> b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
>> index 6fc3902..786ffc6 100644
>> --- a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
>> +++ b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
>> @@ -378,10 +378,10 @@ int arch_misc_init(void)
>>   }
>>   #endif /* CONFIG_ARCH_MISC_INIT */
>>
>> -#ifdef CONFIG_KIRKWOOD_EGIGA
>> +#ifdef CONFIG_MV_EGIGA
>>   int cpu_eth_init(bd_t *bis)
>>   {
>> -kirkwood_egiga_initialize(bis);
>> +mv_egiga_initialize(bis);
>>  return 0;
>>   }
>>   #endif
>> diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
>> b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
>> index 2470efb..9200605 100644
>> --- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
>> +++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
>> @@ -60,6 +60,11 @@
>>   #define KW_EGIGA0_BASE (KW_REGISTER(0x72000))
>>   #define KW_EGIGA1_BASE (KW_REGISTER(0x76000))
>>
>> +#if defined (CONFIG_MV_EGIGA)
> I think you don't need ifdef here
>
>> +#define MV_EGIGA0_BASE  KW_EGIGA0_BASE
>> +#define MV_EGIGA1_BASE  KW_EGIGA1_BASE
>> +#endif
>> +
>>   #if defined (CONFIG_KW88F6281)
>>   #include
>>   #elif defined (CONFIG_KW88F6192)
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
>> index 1599c26..04f8de0 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -52,7 +52,7 @@ COBJS-$(CONFIG_MACB) += macb.o
>>   COBJS-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
>>   COBJS-$(CONFIG_MPC5xxx_FEC) += mpc5xxx_fec.o
>>   COBJS-$(CONFIG_MPC512x_FEC) += mpc512x_fec.o
>> -COBJS-$(CONFIG_KIRKWOOD_EGIGA) += mv_egiga.o
>> +COBJS-$(CONFIG_MV_EGIGA) += mv_egiga.o
>>   COBJS-$(CONFIG_NATSEMI) += natsemi.o
>>   COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
>>   COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o ne2000_base.o
>> diff --git a/drivers/net/mv_egiga.c b/drivers/net/mv_egiga.c
>> index b7ecc9d..4fecf1e 100644
>> --- a/drivers/net/mv_egiga.c
>> +++ b/drivers/net/mv_egiga.c
>> @@ -35,13 +35,17 @@
>>   #include
>>   #include
>>   #include
>> +
>> +#if defined (CONFIG_KIRKWOOD)
>>   #include
>> +#endif
>> +
>>   #include "mv_egiga.h"
>>
>>   DECLARE_GLOBAL_DATA_PTR;
>>
>> -#define KIRKWOOD_PHY_ADR_REQUEST 0xee
>> -#define KWGBE_SMI_REG (((struct kwgbe_registers
>> *)KW_EGIGA0_BASE)->smi)
>> +#define MV_PHY_ADR_REQUEST 0xee
>> +#define MV_EGIGA_SMI_REG (((struct mv_egiga_registers
>> *)MV_EGIGA0_BASE)->smi)
>>
>>   /*
>>* smi_reg_read - miiphy_read callback function.
>> @@ -51,16 +55,16 @@ DECLARE_GLOBAL_DATA_PTR;
>>   static int smi_reg_read(char *devname, u8 phy_adr, u8
>> reg_ofs, u16 * data)
>>   {
>>  struct eth_device *dev = eth_get_dev_by_name(devname);
>> -struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
>> -struct kwgbe_registers *regs = dkwgbe->regs;
>> +struct mv_egiga_device *dmvegiga = to_mv_egiga(dev);
>> +struct mv_egiga_registers *regs = dmvegiga->regs;
> I suggest to keep name as mvgbe here instead of mv_egiga, 3 additional chars, 
> increases overall code size
huh?  The name is consistent with the rest of his work, and *if* the 
code really increases in size, I can't imagine that 3 chars really 
matters...
>>  u32 smi_reg;
>>  u32 timeout;
>>
>>  /* Phyadr read request */
>> -if (phy_adr == KIRKWOOD_PHY_ADR_REQUEST&&
>> -reg_ofs == KIRKWOOD_PHY_ADR_REQUEST) {
>> +if (phy_adr == MV_PHY_ADR_REQUEST&&
>> +reg_ofs == MV_PHY_ADR_REQUEST) {
>>  /* */
>> -*data = (u16) (KWGBEREG_RD(regs->phyadr)&  PHYADR_MASK);
>> +*data = (u16) (MV_EGIGA_REG_RD(regs->phyadr)&
> Same her

Re: [U-Boot] [PATCH] smc91xx_eeprom: Correct chip detection check.

[Ben Warren]

  On 7/9/2010 3:11 PM, Mike Frysinger wrote:
> On Saturday, June 12, 2010 15:22:01 Juergen Kilb wrote:
>> Signed-of-by: Juergen Kilb
> should be "off", not "of".  you'll have to fix the commit in your net/next
> tree too Ben ...
> -mike
thanks for pointing this out.  I'll take care of it this W/E

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] PXA: Voipac PXA270 Support

[Ben Warren]

Hi Marek,

On 7/5/2010 6:16 PM, Marek Vasut wrote:
> This patch adds support for the Voipac PXA270 board. The support includes:
> - Ethernet
> - USB
> - MMC
> - NOR Booting
> - OneNAND Booting
> - LCD
> - HDD
>
> Signed-off-by: Marek Vasut
> ---
>

> +#define  CONFIG_NETMASK  255.255.255.0
> +#define  CONFIG_IPADDR   192.168.1.52
> +#define  CONFIG_SERVERIP 192.168.1.51
> +#define  CONFIG_ETHADDR  00:11:22:33:44:55
> +#endif
> +
>
Please remove these.  The same goes for the other boards.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] ARM: Rename kirkwood_egiga driver to egiga

[Ben Warren]

Hi Albert,

On 7/2/2010 9:53 AM, Albert Aribaud wrote:
> The names of the egiga files mention kirkwood
> even though they are not kirkwood-specific - change them.
>
>
I'm not a git expert so there may be a better way than this, but we want 
this to show up as a rename, rather than an add/delete.  I would 
accomplish this using 'git mv', followed by 'git format-patch -C'

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Micrel Controller KSZ8841-16MBL

[Ben Warren]

Hi Steve,

On 7/1/2010 10:25 AM, Steve Sakoman wrote:
> On Tue, Jun 29, 2010 at 8:08 AM, Douglas Lopes Pereira
>   wrote:
>
>> Hi Steve.
>> Did you succeed on running the driver for KS8841? Did you have to change
>> anything?
>> We are debugging it and some modifications might be necessary for our
>> platform.
>>  
> Well, after taking a  look at the KS8841 driver it didn't look like
> the KS8851 was software compatible.
>
> I'm waiting for a response from Micrel regarding their sample KS8851
> u-boot driver code.  After I hear back from them I'll put together
> some sort of plan, but things are on hold till they respond.
>
>
Good luck with that.  I predict that you will learn nothing new.  Is the 
register layout different on the KS8851, or just the physical link (SPI 
vs memory bus)?

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] smc911x_eeprom

[Ben Warren]

Hi Sergey,

On 6/29/2010 7:59 AM, Sergey Alyoshin wrote:

smc911x_eeprom: smc911x_detect_chip() function return 0 on success

diff --git a/examples/standalone/smc911x_eeprom.c
b/examples/standalone/smc911x_eeprom.c
index 104047f..cb3c131 100644
--- a/examples/standalone/smc911x_eeprom.c
+++ b/examples/standalone/smc911x_eeprom.c
@@ -240,7 +240,7 @@ static void dump_eeprom(struct eth_device *dev)
  static int smc911x_init(struct eth_device *dev)
  {
/* See if there is anything there */
-   if (!smc911x_detect_chip(dev))
+   if (smc911x_detect_chip(dev))
return 1;

smc911x_reset(dev);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
   
Somebody beat you to it.  See commit 
88fd3dbe7dac275bc2ae7727c7ebd293c53780c0 in net/next.


regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Link problem with eTSEC2 on P2020RDB

[Ben Warren]

Hi Felix,

On Fri, Jun 25, 2010 at 4:33 AM, Felix Radensky wrote:

> Hi Ben,
>
> Peter Tyser seems to be OOO until Monday, so maybe you can comment on this
> problem,
> as it's network related.
>
> Peter's patch comes to fix a problem with ethernet not working on XES 8572
> board using
> BCM5482S PHY in SGMII mode.  On the other hand it breaks eTSEC2 on P2020RDB
> board using VSC8211 PHY in SGMII mode. On P2020RDB not only u-boot, but
> also
> Linux cannot use eTSEC2.
>
>
Do you have any suggestions how to make both boards happy ?
>
> I'm not familiar with how SGMII is configured on this controller, but it
appears that Peter's patch turned of Autonegotiation.  Why this would make a
PHY work and a switch not work is curious...  Maybe we should have a CONFIG
option for SGMII parameters.  Settings could default to the ones Peter set
(since he submitted it in November and problems are surfacing now), but
could be overriden.  Does that sound reasonable?  Something like:

#ifndef CONFIG TSEC_TBICR_SETTINGS

#define TBICR_SETTINGS ( \
TBICR_PHY_RESET \
| TBICR_FULL_DUPLEX \
| TBICR_SPEED1_SET \
)

#else

#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS

#endif

> Thanks.
>
> Felix.

If you put together a patch that does this and test it on your board, that
should be good enough.  Peter can try it out when he gets back.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Micrel Controller KSZ8841-16MBL

[Ben Warren]

Hi Steve,

On 6/22/2010 4:44 PM, Steve Sakoman wrote:
> On Tue, Jun 15, 2010 at 9:14 AM, Ben Warren  wrote:
>
>> Hi Douglas,
>>
>> On Tue, Jun 15, 2010 at 7:24 AM, Douglas Lopes Pereira<
>> douglaslopespere...@gmail.com>  wrote:
>>
>>  
>>> Hi all,
>>>
>>> I managed to get KS8841 driver recognized by u-boot. But I'm certain that
>>> it was not in the correct way.
>>>
>>> The driver I've found on BlackFin forum was written for a 2008 u-boot
>>> version and we are working on a 1.3.1 (very old) version. So I just modify
>>> some function calls.
>>>
>>> The problem is that the KS8841 driver does not have a ks884x_initialize
>>> function. So we created it. All it does is create and fill an eth_device
>>> structure. Register it using eth_register function and them it should
>>> initialize the PHY (that is what I suppose it should do).
>>>
>>> Since I am not sure on how to do that, I just called the ks884x_init
>>> function.
>>>
>>> It ends in a TRAP message just after the Micrel device being printed at the
>>> console.
>>>
>>> Could anyone point me out some directions to get my driver correctly
>>> initialized?
>>>
>>> Looks like that driver's using the old API.  I have my new one almost
>>>
>> finished and will send it to you today.  Hopefully debugging it will be
>> trivial.
>>  
> I've just started looking at doing a KS8851 driver (on SPI) for one of
> the OMAP4 boards.
>
> Did you start from scratch with the KS8841 driver or did you begin
> with Micrel sample code?
>
> The Micrel sample u-boot driver clearly can't be used as is since it
> doesn't even come close to following the coding style guidelines
> (CamelCase, etc) and is for an older u-boot revision.
>
> I'm debating whether it makes more sense to correct the coding style
> on the vendor code, or just start from scratch.  Any advice based on
> your experience?
>
>
A few years ago I wrote a driver for KS8841 and got it working (16-bit 
memory-mapped on PowerPC).  I started with the Micrel driver, but as you 
know it's pretty ugly.  Last week I dusted off that old driver and got 
it to compile with the latest U-boot, but wasn't able to test it because 
the company that I worked for is long gone.  It's hopefully close to 
functional, but still has too many style issues to post publicly.  I 
sent the driver to Douglas off-line, and am awaiting feedback.  If you'd 
like, I can send it to you too.  It'd be nice to have a single driver 
that handles different chips, but with configurable accessors.
> Steve
>
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MPC8308ERDB: minimal support for devboard from Freescale

[Ben Warren]

Wolfgang & Ilya,

Sorry for responding to both of you at the same time...

On 6/22/2010 11:14 AM, Wolfgang Denk wrote:
> Dear Ilya Yanok,
>
> In message<4c1f5a54.4050...@emcraft.com>  you wrote:
>
>>  
>>> Entry to MAINTAINERS missing.
>>>
>> Should I add you as a maintainer or myself?
>>  
> You did the actual work...
>
>
 +int board_eth_init(bd_t *bis)
 +{
 +  cpu_eth_init(bis);  /* Initialize TSECs first */

  
>>> I think it's wrong to ignore the return code here.
>>>
>> What makes you think so? What can we do with the return code here? Print
>> warning? If we return error from board_eth_init() calling code will call
>> cpu_eth_init() again which is useless as we have already called it.
>>  
>
Yes, print a warning if < 0.  As you've noticed, returning -1 wouldn't 
be good.  I'm not aware of a U-boot policy for handling hardware 
problems other than printf.
 +  return pci_eth_init(bis);
  
> My understanding is that pci_eth_init() and board_eth_init() return
> the number of NIC's found - should that number not include the number
> of successfully initialized TSECs?
>
>
Yes, please.  Something like:

int board_eth_init(bd_t *bis)
{
 int rc, num_if = 0;
 if ((rc = cpu_eth_init(bis)) >= 0)
 {
 num_if += rc;
 } else {
 print error message
 }
 if ((rc = pci_eth_init(bis)) >= 0)
 {
 num_if += rc;
 } else {
 print error message
 }
 return num_if;
}

I'm working on changing net/eth.c to be less kludgy, but am having a 
hard time setting up my test bed.  Hopefully in the next few days.

> Best regards,
>
> Wolfgang Denk
>
>
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] AX88180: use standard I/O accessors

[Ben Warren]

Hi Mike,

On 6/21/2010 10:25 AM, Mike Frysinger wrote:
> On Monday, June 21, 2010 01:41:54 Ben Warren wrote:
>
>> On 6/2/2010 6:03 PM, Mike Frysinger wrote:
>>  
>>> The current dm9000x driver accesses its memory mapped registers directly
>>> instead of using the standard I/O accessors.  This can cause problems on
>>> Blackfin systems as the accesses can get out of order.  So convert the
>>> direct volatile dereferences to use the normal in/out macros.
>>>
>>> Signed-off-by: Mike Frysinger
>>> Tested-by: Hoan Hoang
>>> ---
>>>
>> I can't get this to apply.  Please rebase against TOT.
>>  
> you need the first two in the series:
> Applying: AX88180: add support for the Marvell 88E1118 phy
> Applying: AX88180: make OUTW handle 32bit/16bit defines too
> -mike
>
Sorry I missed those.  All three are now in net/text.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] at91_emac: Write MAC address automatically

[Ben Warren]

Hi Eric,
On 6/21/2010 12:41 AM, Eric Bénard wrote:
> tested on cpuat91.
>
> Signed-off-by: Eric Bénard
> ---
> v2 :
>   don't check if the MAC address is valid
>
>   drivers/net/at91_emac.c |   28 
>   1 files changed, 20 insertions(+), 8 deletions(-)
>
Applied to net/next repo.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] cpuat91: unbreak ethernet

[Ben Warren]

Hi Eric,

On 6/21/2010 12:40 AM, Eric Bénard wrote:
> * the following problems are met :
> config was set to use the new driver as a default but
> - RMII was not enabled for the new driver
> - the new driver didn't compile with RMII enabled
> - the new driver initialize a PHY at address O when the PHY of
> this board is at 1 thus we get "AT91 EMAC RMII: No PHY present"
>
> * to fix these problems, this patch :
> - enable RMII for the new driver
> - fix the wrong define used in the at91_emac.c
> - allow the config file to set a default phy address (and use
> 0 as a default as in the actual at91_emac.c driver)
>
> Signed-off-by: Eric Bénard
> ---
>
Applied to net/next repo.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][Net] Write MAC address automatically on MACB-based boards

[Ben Warren]

On 6/1/2010 12:03 PM, Ben Warren wrote:
> Also, remove all calls to eth_init() in boards that use MACB
>
> Signed-off-by: Ben Warren
> ---
> Please note: this is untested, but compiles cleanly
>
>   board/afeb9260/afeb9260.c   |7 ---
>   board/atmel/at91cap9adk/at91cap9adk.c   |7 ---
>   board/atmel/at91sam9260ek/at91sam9260ek.c   |7 ---
>   board/atmel/at91sam9263ek/at91sam9263ek.c   |7 ---
>   board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c |7 ---
>   board/calao/sbc35_a9g20/sbc35_a9g20.c   |7 ---
>   board/eukrea/cpu9260/cpu9260.c  |7 ---
>   board/ronetix/pm9263/pm9263.c   |7 ---
>   drivers/net/macb.c  |   23 
> +++
>   9 files changed, 15 insertions(+), 64 deletions(-)
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] smc91xx_eeprom: Correct chip detection check.

[Ben Warren]

Hi Juergen,

On 6/12/2010 12:22 PM, Juergen Kilb wrote:
> From: Juergen Kilb
>
> The smc911x_detect function in /net/driver/net/smc911x.c
> returns a 0 if everything was ok (a chip was found) and -1 else.
> In the standalone example 'smc911x_eeprom' the return value
> of smc911x_detect is interpreted in a different way
> (0 for error, !0 as OK).
> This leads to the error that the chip will not be detected.
>
> Signed-of-by: Juergen Kilb
> ---
>
>   examples/standalone/smc911x_eeprom.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/examples/standalone/smc911x_eeprom.c 
> b/examples/standalone/smc911x_eeprom.c
> index 104047f..cb3c131 100644
> --- a/examples/standalone/smc911x_eeprom.c
> +++ b/examples/standalone/smc911x_eeprom.c
> @@ -240,7 +240,7 @@ static void dump_eeprom(struct eth_device *dev)
>   static int smc911x_init(struct eth_device *dev)
>   {
>   /* See if there is anything there */
> - if (!smc911x_detect_chip(dev))
> + if (smc911x_detect_chip(dev))
>   return 1;
>
>   smc911x_reset(dev);
>
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [v3] tsec: fix the return value for tsec_eth_init()

[Ben Warren]

Timur,
On 6/8/2010 6:21 AM, Timur Tabi wrote:
> The Ethernet initialization functions are supposed to return the number of
> devices initialized, so fix tsec_eth_init() so that they returns the number of
> TSECs initialized, instead of just zero.  This is safe because the return 
> value
> is currently ignored by all callers, but now they don't have to ignore it.
>
> In general, if an function initializes only one device, then it should return
> a negative number if there's an error.  If it initializes more than one 
> device,
> then it should never return a negative number.
>
> Signed-off-by: Timur Tabi
> ---
>   drivers/net/tsec.c |   15 ---
>   1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> index 3e4c3bd..c62ff82 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -95,14 +95,23 @@ static struct tsec_info_struct tsec_info[] = {
>   #endif
>   };
>
> +/*
> + * Initialize all the TSEC devices
> + *
> + * Returns the number of TSEC devices that were initialized
> + */
>   int tsec_eth_init(bd_t *bis, struct tsec_info_struct *tsecs, int num)
>   {
>   int i;
> + int ret, count = 0;
>
> - for (i = 0; i<  num; i++)
> - tsec_initialize(bis,&tsecs[i]);
> + for (i = 0; i<  num; i++) {
> + ret = tsec_initialize(bis,&tsecs[i]);
> + if (ret>  0)
> + count += ret;
> + }
>
> - return 0;
> + return count;
>   }
>
>   int tsec_standard_init(bd_t *bis)
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] uli526x: drop newlines from device name

[Ben Warren]

Hi Mike,
On 6/9/2010 7:14 PM, Mike Frysinger wrote:
> Device names should not contain non-printable characters like newlines.
>
> Signed-off-by: Mike Frysinger
> ---
>   drivers/net/uli526x.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/uli526x.c b/drivers/net/uli526x.c
> index 9477851..56eee7b 100644
> --- a/drivers/net/uli526x.c
> +++ b/drivers/net/uli526x.c
> @@ -225,7 +225,7 @@ int uli526x_initialize(bd_t *bis)
>   iobase&= ~0xf;
>
>   dev = (struct eth_device *)malloc(sizeof *dev);
> - sprintf(dev->name, "uli526x#%d\n", card_number);
> + sprintf(dev->name, "uli526x#%d", card_number);
>   db = (struct uli526x_board_info *)
>   malloc(sizeof(struct uli526x_board_info));
>
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: warn about spaces in device names

[Ben Warren]

Hi Mike,

On 6/9/2010 7:10 PM, Mike Frysinger wrote:
> Some commands operate on eth device names (like 'mii'), but those cannot
> be passed on the command line as one argument.  So detect devices like
> these and warn about them so someone will fix it.
>
> Signed-off-by: Mike Frysinger
> ---
>   net/eth.c |3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/eth.c b/net/eth.c
> index b650a20..40e66e5 100644
> --- a/net/eth.c
> +++ b/net/eth.c
> @@ -225,6 +225,9 @@ int eth_initialize(bd_t *bis)
>   puts (" [PRIME]");
>   }
>
> + if (strchr(dev->name, ' '))
> + puts("\nWarning: eth device name has a 
> space!\n");
> +
>   eth_getenv_enetaddr_by_index(eth_number, env_enetaddr);
>
>   if (memcmp(env_enetaddr, "\0\0\0\0\0\0", 6)) {
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] cpuat91: unbreak ethernet

[Ben Warren]

Hi Eric,

On 6/10/2010 2:50 PM, Eric Bénard wrote:
> * the following problems are met :
> config was set to use the new driver as a default but
> - RMII was not enabled for the new driver
> - the new driver didn't compile with RMII enabled
> - the new driver initialize a PHY at address O when the PHY of
> this board is at 1 thus we get "AT91 EMAC RMII: No PHY present"
>
> * to fix these problems, this patch :
> - enable RMII for the new driver
> - fix the wrong define used in the at91_emac.c
> - allow the config file to set a default phy address (and use
> 0 as a default as in the actual at91_emac.c driver)
>
> Signed-off-by: Eric Bénard
> ---
>   drivers/net/at91_emac.c   |   24 ++--
>   include/configs/cpuat91.h |9 +++--
>   2 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
> index 2399569..1ebcf05 100644
> --- a/drivers/net/at91_emac.c
> +++ b/drivers/net/at91_emac.c
> @@ -53,6 +53,10 @@
>   Please decrease the CONFIG_SYS_RX_ETH_BUFFER value
>   #endif
>
> +#ifndef CONFIG_DRIVER_AT91EMAC_PHYADDR
> +#define CONFIG_DRIVER_AT91EMAC_PHYADDR   0
> +#endif
> +
>   /* MDIO clock must not exceed 2.5 MHz, so enable MCK divider */
>   #if (AT91C_MASTER_CLOCK>  8000)
>   #define HCLK_DIVAT91_EMAC_CFG_MCLK_64
> @@ -198,12 +202,12 @@ static int at91emac_phy_reset(struct eth_device *netdev)
>   emac = (at91_emac_t *) netdev->iobase;
>
>   adv = ADVERTISE_CSMA | ADVERTISE_ALL;
> - at91emac_write(emac, 0, MII_ADVERTISE, adv);
> + at91emac_write(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, MII_ADVERTISE, 
> adv);
>   VERBOSEP("%s: Starting autonegotiation...\n", netdev->name);
> - at91emac_write(emac, 0, MII_BMCR, (BMCR_ANENABLE | BMCR_ANRESTART));
> + at91emac_write(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, MII_BMCR, 
> (BMCR_ANENABLE | BMCR_ANRESTART));
>
This line's too long.  Please check the other ones too.  Try to keep 
less than 78 characters.
>
>   for (i = 0; i<  10 / 100; i++) {
> - at91emac_read(emac, 0, MII_BMSR,&status);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, 
> MII_BMSR,&status);
>   if (status&  BMSR_ANEGCOMPLETE)
>   break;
>   udelay(100);
> @@ -229,13 +233,13 @@ static int at91emac_phy_init(struct eth_device *netdev)
>   emac = (at91_emac_t *) netdev->iobase;
>
>   /* Check if the PHY is up to snuff... */
> - at91emac_read(emac, 0, MII_PHYSID1,&phy_id);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, 
> MII_PHYSID1,&phy_id);
>   if (phy_id == 0x) {
>   printf("%s: No PHY present\n", netdev->name);
>   return 1;
>   }
>
> - at91emac_read(emac, 0, MII_BMSR,&status);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, MII_BMSR,&status);
>
>   if (!(status&  BMSR_LSTATUS)) {
>   /* Try to re-negotiate if we don't have link already. */
> @@ -243,7 +247,7 @@ static int at91emac_phy_init(struct eth_device *netdev)
>   return 2;
>
>   for (i = 0; i<  10 / 100; i++) {
> - at91emac_read(emac, 0, MII_BMSR,&status);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, 
> MII_BMSR,&status);
>   if (status&  BMSR_LSTATUS)
>   break;
>   udelay(100);
> @@ -253,8 +257,8 @@ static int at91emac_phy_init(struct eth_device *netdev)
>   VERBOSEP("%s: link down\n", netdev->name);
>   return 3;
>   } else {
> - at91emac_read(emac, 0, MII_ADVERTISE,&adv);
> - at91emac_read(emac, 0, MII_LPA,&lpa);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, 
> MII_ADVERTISE,&adv);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, 
> MII_LPA,&lpa);
>   media = mii_nway_result(lpa&  adv);
>   speed = (media&  (ADVERTISE_100FULL | ADVERTISE_100HALF)
>? 1 : 0);
> @@ -271,7 +275,7 @@ int at91emac_UpdateLinkSpeed(at91_emac_t *emac)
>   {
>   unsigned short stat1;
>
> - at91emac_read(emac, 0, MII_BMSR,&stat1);
> + at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, MII_BMSR,&stat1);
>
>   if (!(stat1&  BMSR_LSTATUS))/* link status up? */
>   return 1;
> @@ -372,7 +376,7 @@ static int at91emac_init(struct eth_device *netdev, bd_t 
> *bd)
>   value = AT91_EMAC_CFG_CAF | AT91_EMAC_CFG_NBC |
>   HCLK_DIV;
>   #ifdef CONFIG_RMII
> - value |= AT91C_EMAC_RMII;
> + value |= AT91_EMAC_CFG_RMII;
>   #endif
>   writel(value,&emac->cfg);
>
> diff --git a/include/configs/cpuat91.h b/include/configs/cpuat91.h
> index b4fda76..049298c 100644
> --- a/include/configs/cpuat91.h
> +++ b/include/configs/cpuat91.h
> @@ -131,15 +131,12 @@
>   (CONFIG_SYS_MEMTEST_START + PHYS_SDRAM_SIZE - 512 * 1024)
>
>   

Re: [U-Boot] [PATCH 2/2] at91_emac: Write MAC address automatically

[Ben Warren]

Hi Eric,

On 6/15/2010 5:36 AM, Eric Bénard wrote:
> tested on cpuat91.
>
> Signed-off-by: Eric Bénard
> ---
>   drivers/net/at91_emac.c |   31 +++
>   1 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
> index 1ebcf05..ac5903d 100644
> --- a/drivers/net/at91_emac.c
> +++ b/drivers/net/at91_emac.c
> @@ -352,14 +352,6 @@ static int at91emac_init(struct eth_device *netdev, bd_t 
> *bd)
>   writel(1<<  AT91_ID_EMAC,&pmc->pcer);
>   writel(readl(&emac->ctl) | AT91_EMAC_CTL_CSR,&emac->ctl);
>
> - DEBUG_AT91EMAC("init MAC-ADDR %x%x \n",
> - cpu_to_le16(*((u16 *)(netdev->enetaddr + 4))),
> - cpu_to_le32(*((u32 *)netdev->enetaddr)));
> - writel(cpu_to_le32(*((u32 *)netdev->enetaddr)),&emac->sa2l);
> - writel(cpu_to_le16(*((u16 *)(netdev->enetaddr + 4))),&emac->sa2h);
> - DEBUG_AT91EMAC("init MAC-ADDR %x%x \n",
> - readl(&emac->sa2h), readl(&emac->sa2l));
> -
>   /* Init Ethernet buffers */
>   for (i = 0; i<  RBF_FRAMEMAX; i++) {
>   dev->rbfdt[i].addr = (unsigned long) NetRxPackets[i];
> @@ -460,6 +452,28 @@ static int at91emac_recv(struct eth_device *netdev)
>   return 0;
>   }
>
> +static int at91emac_write_hwaddr(struct eth_device *netdev)
> +{
> + emac_device *dev;
> + at91_emac_t *emac;
> + at91_pmc_t *pmc = (at91_pmc_t *) AT91_PMC_BASE;
> +
> + if (netdev->enetaddr != 0) {
>
This check's not necessary.  The caller checks if the MAC address is 
valid ( a more extensive check than you do here)
> + emac = (at91_emac_t *) netdev->iobase;
> + dev = (emac_device *) netdev->priv;
> +
> + writel(1<<  AT91_ID_EMAC,&pmc->pcer);
> + DEBUG_AT91EMAC("init MAC-ADDR %x%x \n",
> + cpu_to_le16(*((u16 *)(netdev->enetaddr + 4))),
> + cpu_to_le32(*((u32 *)netdev->enetaddr)));
> + writel(cpu_to_le32(*((u32 *)netdev->enetaddr)),&emac->sa2l);
> + writel(cpu_to_le16(*((u16 *)(netdev->enetaddr + 
> 4))),&emac->sa2h);
> + DEBUG_AT91EMAC("init MAC-ADDR %x%x \n",
> + readl(&emac->sa2h), readl(&emac->sa2l));
> + }
> + return 0;
> +}
> +
>   int at91emac_register(bd_t *bis, unsigned long iobase)
>   {
>   emac_device *emac;
> @@ -492,6 +506,7 @@ int at91emac_register(bd_t *bis, unsigned long iobase)
>   dev->halt = at91emac_halt;
>   dev->send = at91emac_send;
>   dev->recv = at91emac_recv;
> + dev->write_hwaddr = at91emac_write_hwaddr;
>
>   eth_register(dev);
>
>
regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Add option to disable fibre on M88E1111 PHY for PPC4xx

[Ben Warren]

Hi Stefan,

On 6/10/2010 2:28 AM, Stefan Roese wrote:
> By defining CONFIG_M88E_DISABLE_FIBRE boards can configure the
> M88E PYH to disable fibre. This is needed for an upcoming PPC460GT
> based board, which has fibre/copper auto-selection enabled by default.
> This doesn't seem to work. So we disable fibre in the PHY register.
>
>
I don't mean to be pedantic, but unless this is a Fibre Channel link 
(and it isn't), the appropriate spelling is 'FIBER'.  I say this 
reluctantly, having been raised using British/European spelling...
> Signed-off-by: Stefan Roese
> Cc: Ben Warren
> ---
>   drivers/net/4xx_enet.c |5 +
>   1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c
> index 2fac641..2958903 100644
> --- a/drivers/net/4xx_enet.c
> +++ b/drivers/net/4xx_enet.c
> @@ -1095,6 +1095,11 @@ static int ppc_4xx_eth_init (struct eth_device *dev, 
> bd_t * bis)
>   miiphy_write (dev->name, reg, 0x18, 0x4101);
>   miiphy_write (dev->name, reg, 0x09, 0x0e00);
>   miiphy_write (dev->name, reg, 0x04, 0x01e1);
> +#if defined(CONFIG_M88E_DISABLE_FIBRE)
> + miiphy_read(dev->name, reg, 0x1b,®_short);
> + reg_short |= 0x8000;
> + miiphy_write(dev->name, reg, 0x1b, reg_short);
> +#endif
>   #endif
>   #if defined(CONFIG_M88E1112_PHY)
>   if (bis->bi_phymode[devnum] == BI_PHYMODE_SGMII) {
>
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] AX88180: use standard I/O accessors

[Ben Warren]

Mike,

On 6/2/2010 6:03 PM, Mike Frysinger wrote:
> The current dm9000x driver accesses its memory mapped registers directly
> instead of using the standard I/O accessors.  This can cause problems on
> Blackfin systems as the accesses can get out of order.  So convert the
> direct volatile dereferences to use the normal in/out macros.
>
> Signed-off-by: Mike Frysinger
> Tested-by: Hoan Hoang
> ---
>
I can't get this to apply.  Please rebase against TOT.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] AX88180: switch to common mii.h header

[Ben Warren]

Hi Mike,

On 5/10/2010 1:47 PM, Mike Frysinger wrote:
> No compiled code change here, just drop the local PHY defines in favor of
> the common standard ones.
>
> Signed-off-by: Mike Frysinger
> ---
>   drivers/net/ax88180.c |   31 ---
>   drivers/net/ax88180.h |   48 
> ++--
>   2 files changed, 18 insertions(+), 61 deletions(-)
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] AX88180: improve phy searching

[Ben Warren]

Hi Mike,

On 5/10/2010 1:10 PM, Mike Frysinger wrote:
> Rather than hardcode specific phy addresses, search the possible phy
> address space to find the first available phy.  Also respect the normal
> CONFIG_PHY_ADDR option for board porters to pick a specific address.
>
> Signed-off-by: Mike Frysinger
> ---
>   drivers/net/ax88180.c |   89 
> 
>   drivers/net/ax88180.h |2 -
>   2 files changed, 52 insertions(+), 39 deletions(-)
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] AX88180: fix media typos

[Ben Warren]

Hi Mike,

On 5/10/2010 1:09 PM, Mike Frysinger wrote:
> From: Hoan Hoang
>
> Signed-off-by: Hoan Hoang
> Signed-off-by: Mike Frysinger
> ---
>   drivers/net/ax88180.c |   20 ++--
>   1 files changed, 10 insertions(+), 10 deletions(-)
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] AX88180: add missing init prototype

[Ben Warren]

Hi Mike,

On 5/10/2010 1:08 PM, Mike Frysinger wrote:
> Signed-off-by: Mike Frysinger
> ---
>   include/netdev.h |1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/netdev.h b/include/netdev.h
> index 882642a..99344ce 100644
> --- a/include/netdev.h
> +++ b/include/netdev.h
> @@ -43,6 +43,7 @@ int cpu_eth_init(bd_t *bis);
>   /* Driver initialization prototypes */
>   int altera_tse_initialize(u8 dev_num, int mac_base,
> int sgdma_rx_base, int sgdma_tx_base);
> +int ax88180_initialize(bd_t *bis);
>   int au1x00_enet_initialize(bd_t*);
>   int at91emac_register(bd_t *bis, unsigned long iobase);
>   int bfin_EMAC_initialize(bd_t *bis);
>
Applied to net/next.

regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request - net

[Ben Warren]

Wolfgang,

The following changes since commit 1f241263e088a71b8f33f87b03a37c5418d41e2e:
   Wolfgang Denk (1):
 Merge branch 'fix' of git://git.denx.de/u-boot-pxa

are available in the git repository at:

   git://git.denx.de/u-boot-net.git master

Fillod Stephane (1):
   ip/defrag: fix processing of last short fragment

Wolfgang Denk (1):
   net/eth.c: eth_mac_skip() is only needed when CONFIG_NET_MULTI is set

  net/eth.c |4 ++--
  net/net.c |3 ++-
  2 files changed, 4 insertions(+), 3 deletions(-)

regards,
Ben

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ip/defrag: fix processing of last short fragment

[Ben Warren]

On Saturday, June 19, 2010, Mike Frysinger  wrote:
> On Friday, June 11, 2010 13:26:43 Fillod Stephane wrote:
>> TFTP'ing a file of size 1747851 bytes with CONFIG_IP_DEFRAG and
>> CONFIG_TFTP_BLOCKSIZE set to 4096 fails with a timeout, because
>> the last fragment is not taken into account. This patch fixes
>> IP fragments having less than 8 bytes of payload.
>
> could we get this reviewed/merged before 2010.06 since it looks like kind of a
> bad bug ?

Sure, I'm planning to work through my backlog tonight.
> -mike
>
Regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Micrel Controller KSZ8841-16MBL

[Ben Warren]

Hi Douglas,

On Tue, Jun 15, 2010 at 7:24 AM, Douglas Lopes Pereira <
douglaslopespere...@gmail.com> wrote:

> Hi all,
>
> I managed to get KS8841 driver recognized by u-boot. But I'm certain that
> it was not in the correct way.
>
> The driver I've found on BlackFin forum was written for a 2008 u-boot
> version and we are working on a 1.3.1 (very old) version. So I just modify
> some function calls.
>
> The problem is that the KS8841 driver does not have a ks884x_initialize
> function. So we created it. All it does is create and fill an eth_device
> structure. Register it using eth_register function and them it should
> initialize the PHY (that is what I suppose it should do).
>
> Since I am not sure on how to do that, I just called the ks884x_init
> function.
>
> It ends in a TRAP message just after the Micrel device being printed at the
> console.
>
> Could anyone point me out some directions to get my driver correctly
> initialized?
>
> Looks like that driver's using the old API.  I have my new one almost
finished and will send it to you today.  Hopefully debugging it will be
trivial.

> Thanks for your time.
>
> Regards,
> Douglas
>
> regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/10] nds32: add nds32 board with common support

[Ben Warren]

Hello Macpaul,

On Fri, Jun 11, 2010 at 2:34 AM, Macpaul Lin  wrote:

>Add nds32 based common board related support.
>
> Signed-off-by: Macpaul Lin 
> ---
>  board/AndesTech/common/env.c |  138 ++
>  board/AndesTech/common/flash.c   |  621 +++
>  board/AndesTech/common/flib_flash.c  |  721
> 
>  board/AndesTech/common/flib_serial.c |  373 +
>  board/AndesTech/common/fotg2xx.c |   60 +++
>  board/AndesTech/common/ftmac100.c|  766
> ++
>  board/AndesTech/common/ftpci100.c|  712
> +++
>  board/AndesTech/common/serial.c  |  141 +++
>
Please respect the file hierarchy.  Drivers go in the proper place (e.g.
flib_serial.c should go in drivers/serial, ftmac100.c should go in
drivers/net etc.)


> diff --git a/board/AndesTech/common/ftmac100.c
> b/board/AndesTech/common/ftmac100.c
> new file mode 100644
> index 000..825031d
> --- /dev/null
> +++ b/board/AndesTech/common/ftmac100.c
> @@ -0,0 +1,766 @@
> +/*
> + * Copyright (C) 2009 Andes Technology Corporation
> + * Shawn Lin, Andes Technology Corporation 
> + * Macpaul Lin, Andes Technology Corporation 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +// 
> +// lmc83:  modified from smc9.c (2002-11-29)
> +// 
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "../include/porting.h"
> +#include "../include/ftmac100.h"
> +#include 
> +
> +
> +#ifdef CONFIG_DRIVER_FTMAC100
> +
> +// Use power-down feature of the chip
> +#define POWER_DOWN 0
> +
> +static unsigned char ftmac100_mac_addr[] = {0x00, 0x41, 0x71, 0x99, 0x00,
> 0x00};
>
Please don't make assumptions like this.

> +
> +static const char version[] =
> +   "Faraday FTMAC100 Driver, (Linux Kernel 2.4) 10/18/02 - by
> Faraday\n";
>
I don't think so.

> +
> +#define inl(addr)  (*((volatile u32 *)(addr)))
> +#define inw(addr)  (*((volatile u16 *)(addr)))
> +#define outl(value, addr)  (*((volatile u32 *)(addr)) = value)
> +#define outb(value, addr)  (*((volatile u8 *)(addr)) = value)
>
This isn't the place to define these.

> +
> +struct net_device dev_eth0;
> +int tx_rx_cnt = 0;
> +/*
> + *
> + * Configuration options, for the experienced user to change.
> + *
> + */
> +/*
> + * DEBUGGING LEVELS
> + *
> + * 0 for normal operation
> + * 1 for slightly more details
> + * >2 for various levels of increasingly useless information
> + * 2 for interrupt tracking, status flags
> + * 3 for packet info
> + * 4 for complete packet dumps
> + */
> +
> +#define DO_PRINT(args...) printk(args)
> +
> +//#define FTMAC100_DEBUG 5 // Must be defined in makefile
> +
> +#if (FTMAC100_DEBUG > 2 )
> +#define PRINTK3(args...) DO_PRINT(args)
> +#else
> +#define PRINTK3(args...)
> +#endif
> +
> +#if FTMAC100_DEBUG > 1
> +#define PRINTK2(args...) DO_PRINT(args)
> +#else
> +#define PRINTK2(args...)
> +#endif
> +
> +#ifdef FTMAC100_DEBUG
> +#define PRINTK(args...) DO_PRINT(args)
> +#else
> +#define PRINTK(args...)
> +#endif
>
Please don't do this stuff.  The standard debug() will suffice.

> +
> +
> +///#define FTMAC100_TIMER
> +
> +/*
> + *
> + * The internal workings of the driver.  If you are changing anything
> + * here with the SMC stuff, you should have the datasheet and know
> + * what you are doing.
> + *
> + */
> +#define CARDNAME "FTMAC100"
> +
> +#ifdef FTMAC100_TIMER
> +   static struct timer_list ftmac100_timer;
> +#endif
> +
> +#define ETH_ZLEN 60
> +
> +#ifdef  CONFIG_SMC_USE_32_BIT
>
Please use your own CONFIG

> +#define USE_32_BIT
> +#else
> +#undef USE_32_BIT
>
This sort of thing needs more namespace

> +#endif
> +/*
> + *
> + * The driver can be entered at any of the following entry points.
> + *
> + */
> +
> +extern int eth_init(bd_t *bd);
> +extern void eth_halt(void);
> +extern int eth_rx(void);
> +extern int eth_send(volatile void *packet, int length);
>
You're using an API that's tagged as deprecated.  Please read the
documentation, update the driver to the appropriate API and then we'll
proceed 

Re: [U-Boot] Micrel Controller KSZ8841-16MBL

[Ben Warren]

On Sat, Jun 12, 2010 at 7:35 PM, Mike Frysinger  wrote:

> On Thu, Jun 10, 2010 at 3:18 PM, Ben Warren wrote:
> > Huh? drivers/net/phy does exist...  But the KS8841 is a MAC/PHY, so
> > belongs in driver/net proper.
>
> unrelated, but the current phy/ subdir isnt a phylib setup like linux,
> right ?
>
Not yet.

> -mike
>
--Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Micrel Controller KSZ8841-16MBL

[Ben Warren]

On 6/10/2010 12:02 PM, Douglas Lopes Pereira wrote:
> Hi all,
>
> I need some help here...
>
> I'm working on adding a driver for KSZ8841 ethernet controller which I found
> at this forum: blackfin.uclinux.org.
>
> I was looking at the mail list archive and found a message from Prafulla
> answering Raphael Amorin.
>
> Mr. Prafulla suggested him to add the input code into drivers/net/phy/ and
> public interfaces in netdev.h
>
> Since drivers/net/phy/ does not exist anymore, I'm assuming that input code
> should go to drivers/net/ instead.
>
>
Huh? drivers/net/phy does exist...  But the KS8841 is a MAC/PHY, so 
belongs in driver/net proper.
> But what about the public interfaces (aka. eth_init, eth_send)? Where should
> it go?
>
You're using an out-of-date API.  Please read the documentation 
(doc/README.drivers.eth)

I actually wrote a driver for this controller a few years ago, but 
didn't submit it because at the time it didn't make sense to submit my 
board and we don't allow bare drivers (ones for which there is no 
in-tree board).  If you'd like, I can clean up the driver and send it to 
you, and then put it in the tree.  Unfortunately I don't have hardware 
to test it on anymore.
> Thanks for your time,
> Best regards,
> Douglas
>
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot