Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 11月, 2012 1 次提交
  3. 24 11月, 2012 2 次提交
  5. 21 11月, 2012 3 次提交
  7. 19 11月, 2012 1 次提交
  9. 16 11月, 2012 1 次提交
  11. 15 11月, 2012 2 次提交
    • K
      net/smsc911x: Fix ready check in cases where WORD_SWAP is needed · 769ce4c9
      由 Kamlakant Patel 提交于 
      The chip ready check added by the commit 3ac3546e [Always wait for
the chip to be ready] does not work when the register read/write
is word swapped. This check has been added before the WORD_SWAP
register is programmed, so we need to check for swapped register
value as well.

Bit 16 is marked as RESERVED in SMSC datasheet, Steve Glendinning
<steve@shawell.net> checked with SMSC and wrote:

  The chip architects have concluded we should be reading PMT_CTRL
  until we see any of bits 0, 8, 16 or 24 set.  Then we should read
  BYTE_TEST to check the byte order is correct (as we already do).

  The rationale behind this is that some of the chip variants have
  word order swapping features too, so the READY bit could actually
  be in any of the 4 possible locations.  The architects have confirmed
  that if any of these 4 positions is set the chip is ready.  The other
  3 locations will either never be set or can only go high after READY
  does (so also indicate the device is ready).

This change will check for the READY bit at the 16th position. We do
not check the other two cases (bit 8 and 24) since the driver does not
support byte-swapped register read/write.
Signed-off-by: NKamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      769ce4c9
    • X
      drivers/net: fix tasklet misuse issue · 71c6c837
      由 Xiaotian Feng 提交于 
      In commit 175c0dff, drivers uses tasklet_kill to avoid put disabled tasklet
on the tasklet vec. But some of the drivers uses tasklet_init & tasklet_disable
in the driver init code, then tasklet_enable when it is opened. This makes
tasklet_enable on a killed tasklet and make ksoftirqd crazy then. Normally,
drivers should use tasklet_init/tasklet_kill on device open/remove, and use
tasklet_disable/tasklet_enable on device suspend/resume.
Reported-by: NPeter Wu <lekensteyn@gmail.com>
Tested-by: NPeter Wu <lekensteyn@gmail.com>
Signed-off-by: NXiaotian Feng <dannyfeng@tencent.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71c6c837
  13. 10 11月, 2012 1 次提交
  15. 08 11月, 2012 2 次提交
  17. 04 11月, 2012 4 次提交
  19. 03 11月, 2012 3 次提交
  21. 01 11月, 2012 8 次提交
  23. 26 10月, 2012 4 次提交
  25. 25 10月, 2012 3 次提交
  27. 24 10月, 2012 2 次提交
  29. 23 10月, 2012 3 次提交
    • V
      pch_gbe: don't reset MAC_RX on FIFO overflow · a35279f0
      由 Veaceslav Falico 提交于 
      Currently, when FIFO_ERR happens, we stop the dma, wait for it to become
idle and then reset the whole MAC_RX logic (and after that we must re-set
multicast addresses and also re-enable MAC_RX when we're finally ready to
accept new packets). This leads to CRC errors on high number of incoming
packets and is not needed according to the datasheet.

This patch fixes it by the following steps:

1) remove this reset in pch_gbe_stop_receive(), which causes some functions
to not be used anywhere
2) remove already unused functions pch_gbe_wait_clr_bit_irq() and
pch_gbe_mac_reset_rx() to correctly build
3) move pch_gbe_enable_mac_rx() out of pch_gbe_start_receive() to
pch_gbe_up() where it's only needed after we've removed the MAC_RX reset
4) rename pch_gbe_start/stop_receive() to pch_gbe_enable/disable_dma_rx()
to more precisely reflect what the functions are now doing.

After these changes we already don't see the CRC errors and gain some
increase in RX processing speed.
Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a35279f0
    • V
      pch_gbe: don't re-set RX_FIFO_ERR flag in napi_poll · 9c0314e1
      由 Veaceslav Falico 提交于 
      If we were in RX_FIFO_ERR state and entered pch_gbe_napi_poll(), we'll
anyway clean some rx space and thus can continue to receive more packets.
Currently, we re-set the RX_FIFO_ERR in situations when we've exhausted our
budget for RX cleaning or cleaned some TX packets. Removing it gives us
+20%-40% speed increase and a lot less of RX_FIFO_ERRors reported.
Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c0314e1
    • V
      pch_gbe: create functions for MAC_RX {en,dis}able · e408a9ff
      由 Veaceslav Falico 提交于 
      Move MAC_RX-related bits into separate functions.
Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e408a9ff