Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 3月, 2010 1 次提交
  3. 04 3月, 2010 1 次提交
  5. 26 2月, 2010 1 次提交
  7. 20 2月, 2010 1 次提交
    • R
      r8169: enable 64-bit DMA by default for PCI Express devices (v2) · 35317688
      由 Robert Hancock 提交于 
      Currently use of 64-bit DMA is disabled in r8169 unless the user passes the
use_dac module option. This is reasonable for conventional PCI devices where
broken chipsets may not handle dual-address-cycle transfers properly for
32-bit slots and so this may not be safe. However, PCI Express should not have
this problem and not using 64-bit DMA results in DMA transfers needlessly using
the IOMMU or SWIOTLB. Set the use_dac module parameter to a new default value of
-1 which results in 64-bit DMA being enabled by default for PCI Express devices
only.
Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35317688
  9. 13 2月, 2010 2 次提交
  11. 08 1月, 2010 1 次提交
  13. 30 12月, 2009 1 次提交
  15. 16 12月, 2009 1 次提交
  17. 04 12月, 2009 1 次提交
  19. 30 11月, 2009 1 次提交
  21. 26 11月, 2009 1 次提交
  23. 14 11月, 2009 1 次提交
    • R
      r8169: Fix receive buffer length when MTU is between 1515 and 1536 · 8812304c
      由 Raimonds Cicans 提交于 
      In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.

For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22

Bug:
driver for all MTU up to 1536 use receive buffer size 1536

As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.

Example:

host_good>  ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good>  ping host_r8169
Ok
host_good>  ping -s 1500 host_r8169
Fail
host_good>  ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good>  ping -s 1500 host_r8169
Ok

Bonus: got rid of magic number 8
Signed-off-by: NRaimonds Cicans <ray@apollo.lv>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8812304c
  25. 30 10月, 2009 1 次提交
  27. 24 10月, 2009 1 次提交
    • S
      r8169: fix Ethernet Hangup for RTL8110SC rev d · 05af2142
      由 Simon Wunderlich 提交于 
      The 8110SC rev d chip on our board shows a regression which the 8110SB chip
did not have. When inbound traffic is overflowing the receive descriptor queue,
"holes" in the ring buffer may occur which lead to a hangup until the buffer
is filled again. The packets are than completely processed, but the ring
remains porous and no packets are processed until the next overflow. Setting
the interface down and up can fix the problem temporary from userspace.

For some reason we don't know, this behaviour is not occuring if the RxVlan
bit for hardware VLAN untagging is set. There is another "Work around for
AMD plateform" in the current code which checks the VLAN status
word in receive descriptors, but does never come to effect when hardware
VLAN support is enabled. We assume that this is a bug in the chip.

The following patch fixes the problem. Without the patch we could reproduce
the hang within minutes (given other devices also generating lots of
interrupts), without we couldn't reproduce within a few days of long term
testing.

This version contains minor style adjustments and is sent with mutt which
will hopefully not destroy the formatting again.
Signed-off-by: NBernhard Schmidt <bernhard.schmidt@saxnet.de>
Signed-off-by: NSimon Wunderlich <simon.wunderlich@saxnet.de>
Acked-by: NFrancois Romieu <romieu@zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05af2142
  29. 14 10月, 2009 2 次提交
  31. 07 9月, 2009 1 次提交
  33. 04 9月, 2009 1 次提交
  35. 01 9月, 2009 1 次提交
  37. 13 8月, 2009 6 次提交
  39. 27 7月, 2009 1 次提交
  41. 19 6月, 2009 1 次提交
  43. 18 6月, 2009 1 次提交
  45. 11 6月, 2009 1 次提交
  47. 09 6月, 2009 1 次提交
  49. 29 5月, 2009 1 次提交
  51. 27 5月, 2009 1 次提交
  53. 26 5月, 2009 1 次提交
    • D
      r8169: avoid losing MSI interrupts · f11a377b
      由 David Dillow 提交于 
      The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.

The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.
Signed-off-by: NDavid Dillow <dave@thedillows.org>
Tested-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f11a377b
  55. 20 5月, 2009 2 次提交
  57. 14 4月, 2009 1 次提交
    • R
      NET/r8169: Rework suspend and resume · 861ab440
      由 Rafael J. Wysocki 提交于 
      The recent changes of the PCI PM core allow us to simplify the
suspend and resume handling in a number of device drivers, since they
don't need to carry out the general PCI PM operations, such as
changing the power state of the device, during suspend and resume any
more.

Simplify the suspend and resume callbacks of r8169 using the
observation that the PCI PM core can take care of some operations
carried out by the driver.

Additionally, make the shutdown callback of r8169 only put the device
into a low power state if the system is going to be powered off
(kexec is known to have problems with network adapters that are put
into low power states on shutdown).

This patch has been tested on MSI Wind U100.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      861ab440
  59. 07 4月, 2009 2 次提交
  61. 02 4月, 2009 1 次提交