1. 22 7月, 2015 1 次提交
    • S
      dm: eth: Avoid blocking on packet reception · a1ca92ea
      Simon Glass 提交于
      Some devices can take a long time to work out whether they have a new packet
      or now. For example the ASIX USB Ethernet dongle can take 5 seconds to do
      this, since it waits until it gets a new packet on the wire before allowing
      the USB bulk read packet to be submitted.
      
      At present with driver mode the Ethernet receive code reads 32 packets. This
      can take a very long time if we must wait for all 32 packets. The old code
      (before driver model) worked by reading a single set of packets from the USB
      device, then processing all the packets with in. It would be nice to use
      the same behaviour with driver model.
      
      Add a flag to the receive method which indicates that the driver should try
      to find a packet if available, by consulting the hardware. When the flag is
      not set, it should just return any packet data it has already received. If
      there is none, it should return -EAGAIN so that the loop will terminate.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      a1ca92ea
  2. 19 4月, 2015 26 次提交
  3. 25 3月, 2015 1 次提交
  4. 13 2月, 2015 1 次提交
  5. 24 1月, 2015 1 次提交
  6. 15 1月, 2015 1 次提交
  7. 10 10月, 2014 1 次提交
    • W
      SPDX License cleanup for LiMon imported files · 2ea91039
      Wolfgang Denk 提交于
      A number of network related files were imported from the LiMon
      project; these contain a somewhat unclear license statement:
      
      	Copyright 1994 - 2000 Neil Russell.
      	(See License)
      
      I analyzed the source code of LiMon v1.4.2 which was used for this
      import.  It does not contain any "License" file, but the top level
      directory contains a file "COPYING", which turns out to be GPL v2
      of June 1991.  So it is legitimate to conclude that the LiMon derived
      files are also to be released under GPLv2.  Mark them as such.
      Signed-off-by: NWolfgang Denk <wd@denx.de>
      2ea91039
  8. 13 5月, 2014 1 次提交
  9. 23 11月, 2013 1 次提交
    • C
      net: Fix mcast function pointer prototype · 9c4cffac
      Claudiu Manoil 提交于
      This fixes the following compiler warnings when activating
      CONFIG_MCAST_TFTP:
      
      tsec.c: In function 'tsec_mcast_addr':
      tsec.c:130:2: warning: passing argument 2 of 'ether_crc' makes pointer
      from integer without a cast [enabled by default]
      In file included from /work/u-boot-net/include/common.h:874:0,
                       from tsec.c:15:
      /work/u-boot-net/include/net.h:189:5: note: expected 'const unsigned
      char *' but argument is of type 'u8'
      tsec.c: In function 'tsec_initialize':
      tsec.c:646:13: warning: assignment from incompatible pointer type
      [enabled by default]
      eth.c: In function 'eth_mcast_join':
      eth.c:358:2: warning: passing argument 2 of 'eth_current->mcast' makes
      integer from pointer without a cast [enabled by default]
      eth.c:358:2: note: expected 'u32' but argument is of type 'u8 *'
      
      In the eth_mcast_join() implementation, eth_current->mcast()
      takes a u8 pointer to the multicast mac address and not a ip
      address value as implied by its prototype.
      
      Fix parameter type mismatch for tsec_macst_addr() (tsec.c):
      ether_crc() takes a u8 pointer not a u8 value.
      mcast() is given a u8 pointer to the multicats mac address.
      Update parameter type for the rest of mcast() instances.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Patch: 278989
      9c4cffac
  10. 20 8月, 2013 1 次提交
  11. 25 6月, 2013 1 次提交
  12. 05 6月, 2013 1 次提交
  13. 05 11月, 2012 1 次提交
    • K
      net/: sparse fixes · 06370590
      Kim Phillips 提交于
      bootp.c:44:14: warning: symbol 'dhcp_state' was not declared. Should it be static?
      bootp.c:45:15: warning: symbol 'dhcp_leasetime' was not declared. Should it be static?
      bootp.c:46:10: warning: symbol 'NetDHCPServerIP' was not declared. Should it be static?
      arp.c:30:17: warning: symbol 'NetArpWaitReplyIP' was not declared. Should it be static?
      arp.c:37:16: warning: symbol 'NetArpTxPacket' was not declared. Should it be static?
      arp.c:38:17: warning: symbol 'NetArpPacketBuf' was not declared. Should it be static?
      atheros.c:33:19: warning: symbol 'AR8021_driver' was not declared. Should it be static?
      net.c:183:7: warning: symbol 'PktBuf' was not declared. Should it be static?
      net.c:159:21: warning: symbol 'net_state' was not declared. Should it be static?
      ping.c:73:6: warning: symbol 'ping_start' was not declared. Should it be static?
      ping.c:82:13: warning: symbol 'ping_receive' was not declared. Should it be static?
      tftp.c:53:7: warning: symbol 'TftpRRQTimeoutMSecs' was not declared. Should it be static?
      tftp.c:54:5: warning: symbol 'TftpRRQTimeoutCountMax' was not declared. Should it be static?
      eth.c:125:19: warning: symbol 'eth_current' was not declared. Should it be static?
      
      Note: in the ping.c fix, commit a36b12f9
      "net: Move PING out of net.c" mistakenly carried the ifdef CMD_PING
      clause from when it was necessary to avoid warnings when it was embedded
      in net.c.
      Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
      06370590
  14. 25 9月, 2012 2 次提交
    • J
      net: Filter incoming netconsole packets by IP · 8a0eccb1
      Joe Hershberger 提交于
      Check the incoming packets' source IP address... if ncip isn't set to a
      broadcast address, only listen to the client at ncip.
      Signed-off-by: NJoe Hershberger <joe.hershberger@ni.com>
      8a0eccb1
    • J
      net: Improve the speed of netconsole · f8be7d65
      Joe Hershberger 提交于
      Previously u-boot would initialize the network interface for every
      network operation and then shut it down again.  This makes sense for
      most operations where the network in not known to be needed soon after
      the operation is complete.  In the case of netconsole, it will use the
      network for every interaction with the shell or every printf.  This
      means that the network is being reinitialized very often.  On many
      devices, this intialization is very slow.
      
      This patch checks for consecutive netconsole actions and leaves the
      ethernet hardware initialized between them.  It will still behave the
      same old way for all other network operations and any time another
      network operation happens between netconsole operations.
      Signed-off-by: NJoe Hershberger <joe.hershberger@ni.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Acked-by: NStefano Babic <sbabic@denx.de>
      f8be7d65