1. 06 8月, 2013 1 次提交
    • C
      gianfar: Fix Tx csum generation errata handling · 02d88fb4
      Claudiu Manoil 提交于
      Both [eTSEC76] and [eTSEC12] errata relate to Tx checksum generation
      (for some MPC83xx and MCP8548 older revisions). They require the same
      workaround: manual checksum computation and insertion, and disabling
      the H/W Tx csum acceleration feature (per frame) through Tx FCB
      (Frame Control Block) csum offload settings.
      
      The workaround for [eTSEC76] needs to be fixed because it currently
      fails to disable H/W Tx csum insertion via FCB. This patch fixes it
      and provides a common workaround implementation for both Tx csum errata.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02d88fb4
  2. 02 8月, 2013 1 次提交
  3. 31 7月, 2013 1 次提交
  4. 28 7月, 2013 1 次提交
    • F
      net: fec: workaround stop tx during errata ERR006358 · 03191656
      Frank Li 提交于
      If the ready bit in the transmit buffer descriptor (TxBD[R])
      is previously detected as not set during a prior frame transmission,
      then the ENET_TDAR[TDAR] bit is cleared at a later time, even if
      additional TxBDs were added to the ring and the ENET_TDAR[TDAR]
      bit is set. This results in frames not being transmitted until
      there is a 0-to-1 transition on ENET_TDAR[TDAR].
      
      Workarounds:
      code can use the transmit frame interrupt flag (ENET_EIR[TXF])
      as a method to detect whether the ENET has completed transmission
      and the ENET_TDAR[TDAR] has been cleared. If ENET_TDAR[TDAR] is
      detected as cleared when packets are queued and waiting for transmit,
      then a write to the TDAR bit will restart TxBD processing.
      
      This case main happen when loading is light. A ethernet package may
      not send out utile next package put into tx queue.
      
      How to test:
      while [ true ]
      do
      	ping <IP> -s 10000 -w 4
      	ping <IP> -s 6000 -w 2
      	ping <IP> -s 4000 -w 2
      	ping <IP> -s 10000 -w 2
      done
      
      You will see below result in overnight test.
      
      6008 bytes from 10.192.242.116: seq=1 ttl=128 time=0.722 ms
      4008 bytes from 10.192.242.116: seq=0 ttl=128 time=1001.008 ms
      4008 bytes from 10.192.242.116: seq=1 ttl=128 time=1.010 ms
      10008 bytes from 10.192.242.116: seq=0 ttl=128 time=0.896 ms
      
      After apply this patch, >1000ms delay disappear.
      Signed-off-by: NFrank Li <Frank.Li@freescale.com>
      Acked-by: NFugang Duan  <B38611@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03191656
  5. 24 7月, 2013 1 次提交
  6. 23 7月, 2013 6 次提交
  7. 04 7月, 2013 1 次提交
  8. 03 7月, 2013 1 次提交
  9. 02 7月, 2013 2 次提交
  10. 27 6月, 2013 1 次提交
  11. 20 6月, 2013 2 次提交
    • B
      net: Move MII out from under NET_CORE and hide it · a1606c7d
      Ben Hutchings 提交于
      All drivers that select MII also need to select NET_CORE because MII
      depends on it.  This is a bit ridiculous because NET_CORE is just a
      menu option that doesn't enable any code by itself.
      
      There is also no need for it to be a visible option, since its users
      all select it.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1606c7d
    • G
      net: fec: Fix build for MCF5272 · d1391930
      Guenter Roeck 提交于
      Commits 4c09eed9 (net: fec: Enable imx6 enet checksum acceleration) and
      baa70a5c (net: fec: enable pause frame to improve rx prefomance for 1G
      network) introduced functionality into the FEC driver which is not
      supported on MCF5272. The registers used to implement this functionality
      do not exist on MCF5272. Since register defines for MCF5272 are separate
      from register defines for other chips, building images for MCF5272 fails
      as follows.
      
      fec_main.c: In function 'fec_restart':
      fec_main.c:520:8: error: 'FEC_RACC' undeclared (first use in this function)
      fec_main.c:585:3: error: 'FEC_R_FIFO_RSEM' undeclared (first use in this function)
      fec_main.c:586:3: error: 'FEC_R_FIFO_RSFL' undeclared (first use in this function)
      fec_main.c:587:3: error: 'FEC_R_FIFO_RAEM' undeclared (first use in this function)
      fec_main.c:588:3: error: 'FEC_R_FIFO_RAFL' undeclared (first use in this function)
      fec_main.c:591:3: error: 'FEC_OPD' undeclared (first use in this function)
      
      Adding the missing register defines is not an option, since the registers
      do not exist on MCF5272. Disable the added functionality for MCF5272 builds.
      
      Cc: Frank Li <Frank.Li@freescale.com>
      Cc: Jim Baxter <jim_baxter@mentor.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1391930
  12. 18 6月, 2013 1 次提交
  13. 12 6月, 2013 2 次提交
  14. 08 6月, 2013 1 次提交
  15. 05 6月, 2013 1 次提交
  16. 28 5月, 2013 6 次提交
  17. 26 5月, 2013 1 次提交
  18. 23 5月, 2013 2 次提交
  19. 21 5月, 2013 1 次提交
  20. 18 5月, 2013 1 次提交
  21. 16 5月, 2013 2 次提交
    • F
      fec: Invert the order of function calls in fec_restart() · 1ed0d56c
      Fabio Estevam 提交于
      commit 54309fa6 ("net: fec: fix kernel oops when plug/unplug cable many times")
      introduced the following 'if' block in the beginning of fec_start():
      
      	if (netif_running(ndev)) {
      		netif_device_detach(ndev);
      		napi_disable(&fep->napi);
      		netif_stop_queue(ndev);
      		netif_tx_lock_bh(ndev);
      	}
      
      Then later in the end of fec_restart() there is another block that calls the
      opposite of each one of these functions.
      
      The correct approach would be to also call them with in the reverse order, so
      that we have as result:
      
      	if (netif_running(ndev)) {
      		netif_tx_unlock_bh(ndev);
      		netif_wake_queue(ndev);
      		napi_enable(&fep->napi);
      		netif_device_attach(ndev);
      	}
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ed0d56c
    • F
      fec: Fix inconsistent lock state · 31691344
      Fabio Estevam 提交于
      fec_restart() runs in softirq context and we should use the
      netif_tx_lock_bh/netif_tx_unlock_bh() variants to avoid the following warning
      that happens since commit 54309fa6 ("net: fec: fix kernel oops when plug/unplug
      cable many times"):
      
      [    9.753168] =================================
      [    9.757540] [ INFO: inconsistent lock state ]
      [    9.761921] 3.10.0-rc1-next-20130514 #13 Not tainted
      [    9.766897] ---------------------------------
      [    9.771264] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [    9.777288] swapper/0 [HC0[0]:SC1[3]:HE1:SE0] takes:
      [    9.782261]  (_xmit_ETHER#2){+.?...}, at: [<c03c24a4>] sch_direct_xmit+0xa0/0x2d4
      [    9.789879] {SOFTIRQ-ON-W} state was registered at:
      [    9.794769]   [<c0059c60>] __lock_acquire+0x528/0x1bc0
      [    9.799953]   [<c005b838>] lock_acquire+0xa0/0x108
      [    9.804780]   [<c0441320>] _raw_spin_lock+0x28/0x38
      [    9.809702]   [<c02f9fc8>] fec_restart+0x5d0/0x664
      [    9.814542]   [<c02fa738>] fec_enet_adjust_link+0xa8/0xc0
      [    9.819978]   [<c02f7a28>] phy_state_machine+0x2fc/0x370
      [    9.825323]   [<c0035ee0>] process_one_work+0x1c0/0x4a0
      [    9.830589]   [<c0036594>] worker_thread+0x138/0x394
      [    9.835587]   [<c003c620>] kthread+0xa4/0xb0
      [    9.839890]   [<c000e820>] ret_from_fork+0x14/0x34
      [    9.844728] irq event stamp: 185984
      [    9.848226] hardirqs last  enabled at (185984): [<c00232b0>] local_bh_enable_ip+0x84/0xf0
      [    9.856450] hardirqs last disabled at (185983): [<c0023270>] local_bh_enable_ip+0x44/0xf0
      [    9.864667] softirqs last  enabled at (185966): [<c0023470>] irq_enter+0x64/0x68
      [    9.872099] softirqs last disabled at (185967): [<c0023510>] irq_exit+0x9c/0xd8
      [    9.879440]
      [    9.879440] other info that might help us debug this:
      [    9.885981]  Possible unsafe locking scenario:
      [    9.885981]
      [    9.891912]        CPU0
      [    9.894364]        ----
      [    9.896814]   lock(_xmit_ETHER#2);
      [    9.900259]   <Interrupt>
      [    9.902884]     lock(_xmit_ETHER#2);
      [    9.906500]
      [    9.906500]  *** DEADLOCK ***
      Reported-by: NShawn Guo <shawn.guo@linaro.org>
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31691344
  22. 12 5月, 2013 1 次提交
  23. 09 5月, 2013 1 次提交
  24. 25 4月, 2013 2 次提交