Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 10月, 2008 3 次提交
  3. 10 10月, 2008 1 次提交
  5. 09 10月, 2008 3 次提交
  7. 25 9月, 2008 2 次提交
  9. 27 8月, 2008 1 次提交
  11. 17 8月, 2008 6 次提交
  13. 21 7月, 2008 2 次提交
    • M
      r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06 · 77332894
      由 Marcus Sundberg 提交于 
      The magic write to register 0x82 will often cause PCI config space on
my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop)
to be filled with ones during driver load, and thus breaking NIC
operation until reboot. If it does not happen on first driver load it
can easily be reproduced by unloading and loading the driver a few
times.

The magic write was added long ago by this commit:

Author: François Romieu <romieu@fr.zoreil.com>
Date:   Sat Jan 10 06:00:46 2004 -0500

     [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one():
     - phy capability settings allows lower or equal capability as suggested
       in Realtek's changes;
     - I/O voodoo;
     - no need to s/mdio_write/RTL8169_WRITE_GMII_REG/;
     - s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/;
     - rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication
       of code (yep, the u16 -> int conversions should work as expected);
     - variable renames and whitepace changes ignored.

As the 8168 wasn't supported by that version this patch simply removes
the bogus write from mac versions <= RTL_GIGA_MAC_VER_06.

[The change above makes sense for the 8101/8102 too -- Ueimor]
Signed-off-by: NMarcus Sundberg <marcus@ingate.com>
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      77332894
    • F
      r8169: multicast register update · f887cce8
      由 Francois Romieu 提交于 
      The layout of the 8101 series is identical to that of the 8168 one,
thus allowing to pack everything not 8169 related above MAC_VER_06.
New 810x and 8168 chipsets should automagically behave correctly.

It matches code in Realtek's 1.008.00 8101 and 8.007.00 8168 drivers.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      f887cce8
  15. 29 6月, 2008 2 次提交
  17. 18 4月, 2008 2 次提交
  19. 13 1月, 2008 1 次提交
  21. 09 1月, 2008 1 次提交
    • D
      [NET]: Fix drivers to handle napi_disable() disabling interrupts. · d1d08d12
      由 David S. Miller 提交于 
      When we add the generic napi_disable_pending() breakout
logic to net_rx_action() it means that napi_disable()
can cause NAPI poll interrupt events to be disabled.

And this is exactly what we want.  If a napi_disable()
is pending, and we are looping in the ->poll(), we want
->poll() event interrupts to stay disabled and we want
to complete the NAPI poll ASAP.

When ->poll() break out during device down was being handled on a
per-driver basis, often these drivers would turn interrupts back on
when '!netif_running()' was detected.

And this would just cause a reschedule of the NAPI ->poll() in the
interrupt handler before the napi_disable() could get in there and
grab the NAPI_STATE_SCHED bit.

The vast majority of drivers don't care if napi_disable() might have
the side effect of disabling NAPI ->poll() event interrupts.  In all
such cases, when a napi_disable() is performed, the driver just
disabled interrupts or is about to.

However there were three exceptions to this in PCNET32, R8169, and
SKY2.  To fix those cases, at the subsequent napi_enable() points, I
added code to ensure that the ->poll() interrupt events are enabled in
the hardware.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NDon Fry <pcnet32@verizon.net>
      d1d08d12
  23. 23 12月, 2007 1 次提交
  25. 10 11月, 2007 5 次提交
  27. 29 10月, 2007 2 次提交
  29. 19 10月, 2007 8 次提交