1. 23 5月, 2011 2 次提交
    • P
      Add appropriate <linux/prefetch.h> include for prefetch users · 70c71606
      Paul Gortmaker 提交于
      After discovering that wide use of prefetch on modern CPUs
      could be a net loss instead of a win, net drivers which were
      relying on the implicit inclusion of prefetch.h via the list
      headers showed up in the resulting cleanup fallout.  Give
      them an explicit include via the following $0.02 script.
      
       =========================================
       #!/bin/bash
       MANUAL=""
       for i in `git grep -l 'prefetch(.*)' .` ; do
       	grep -q '<linux/prefetch.h>' $i
       	if [ $? = 0 ] ; then
       		continue
       	fi
      
       	(	echo '?^#include <linux/?a'
       		echo '#include <linux/prefetch.h>'
       		echo .
       		echo w
       		echo q
       	) | ed -s $i > /dev/null 2>&1
       	if [ $? != 0 ]; then
       		echo $i needs manual fixup
       		MANUAL="$i $MANUAL"
       	fi
       done
       echo ------------------- 8\<----------------------
       echo vi $MANUAL
       =========================================
      Signed-off-by: NPaul <paul.gortmaker@windriver.com>
      [ Fixed up some incorrect #include placements, and added some
        non-network drivers and the fib_trie.c case    - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70c71606
    • P
      drivers/net: add prefetch header for prefetch users · c0cba59e
      Paul Gortmaker 提交于
      After discovering that wide use of prefetch on modern CPUs
      could be a net loss instead of a win, net drivers which were
      relying on the implicit inclusion of prefetch.h via the list
      headers showed up in the resulting cleanup fallout.  Give
      them an explicit include via the following $0.02 script.
      
       =========================================
       #!/bin/bash
       MANUAL=""
       for i in `git grep -l 'prefetch(.*)' .` ; do
       	grep -q '<linux/prefetch.h>' $i
       	if [ $? = 0 ] ; then
       		continue
       	fi
      
       	(	echo '?^#include <linux/?a'
       		echo '#include <linux/prefetch.h>'
       		echo .
       		echo w
       		echo q
       	) | ed -s $i > /dev/null 2>&1
       	if [ $? != 0 ]; then
       		echo $i needs manual fixup
       		MANUAL="$i $MANUAL"
       	fi
       done
       echo ------------------- 8\<----------------------
       echo vi $MANUAL
       =========================================
      Signed-off-by: NPaul <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0cba59e
  2. 10 5月, 2011 8 次提交
    • F
      r8169: avoid late chip identifier initialisation. · 5d320a20
      Francois Romieu 提交于
      Unknown 8168 chips did not have any PLL power method set as they
      did not inherit a default family soon enough. Fix it.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      5d320a20
    • F
      r8169: merge firmware information into the chipset description data. · 85bffe6c
      Francois Romieu 提交于
      - RTL_GIGA_MAC_NONE is a fake index so put it at the end of the
        enumeration and shift everybody.
      - RTL_GIGA_MAC_VER_17 / RTL_GIGA_MAC_VER_16 ordering fixed. Though
        not wrong it was confusing enough to wonder if things were right.
      
      Renaming rtl_chip_info was not strictly necessary. It allows to
      check the patch for the correct use of the indexes though.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      85bffe6c
    • F
      r8169: provide some firmware information via ethtool. · 31bd204f
      Francois Romieu 提交于
      There is no real firmware version yet but the manpage of ethtool
      is rather terse about the driver information.
      
      Former output:
      $ ethtool -i eth1
      driver: r8169
      version: 2.3LK-NAPI
      firmware-version:
      bus-info: 0000:01:00.0
      $ ethtool -i eth0
      driver: r8169
      version: 2.3LK-NAPI
      firmware-version:
      bus-info: 0000:03:00.0
      
      Current output:
      $ ethtool -i eth1
      driver: r8169
      version: 2.3LK-NAPI
      firmware-version: N/A
      bus-info: 0000:01:00.0
      
      $ ethtool -i eth0
      driver: r8169
      version: 2.3LK-NAPI
      firmware-version: rtl_nic/rtl8168d-1.fw
      bus-info: 0000:03:00.0
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Fixed-by Ciprian Docan <docan@eden.rutgers.edu>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      Cc: Fejes József <fejes@joco.name>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      31bd204f
    • F
      r8169: remove non-NAPI context invocation of rtl8169_rx_interrupt. · 56de414c
      Francois Romieu 提交于
      Invocation of rtl8169_rx_interrupt from rtl8169_reset_task was originally
      intended to retrieve as much packets as possible from the rx ring when a
      reset was needed. Nowadays rtl8169_reset_task is only scheduled, with
      some delay
      a. from the tx timeout watchdog
      b. when resuming
      c. from rtl8169_rx_interrupt itself
      
      It's dubious that the loss of outdated packets will matter much for a)
      and b). c) does not need to call itself again.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      56de414c
    • F
      r8169: link speed selection timer rework. · 4876cc1e
      Francois Romieu 提交于
      The implementation was a bit krusty.
      
      The 10s rtl8169_phy_timer timer has been (was ?) required with older
      8169 for adequate phy operation when full gigabit is advertised in
      autonegotiated mode. The timer does nothing if the link is up.
      Otherwise it keeps resetting the phy until things improve.
      
      - the device private data field phy_1000_ctrl_reg was used to
        schedule the timer. Avoid it and save a few bytes.
      
      - rtl8169_set_settings
        pending timer is disabled before changing the link settings as
        rtl8169_phy_timer is not always needed (see the removed test in
        rtl8169_phy_timer).
      
      - rtl8169_set_speed
        the requested link parameters may not match the chipset : bail out
        early on failure.
      
      - rtl8169_open
        Calling rtl8169_request_timer is redundant with
        -> rtl8169_open
           -> rtl8169_init_phy
              -> rtl8169_set_speed
                 -> mod_timer
        The latter always enables the phy timer whereas the former did not
        for RTL_GIGA_MAC_VER_01. It should not make things worse but only
        time will tell if reality agrees.
      
      - rtl8169_request_timer : unused yet. Removed.
      
      - rtl8169_delete_timer : useless. Bloat. Removed.
      
      Side effect : the timer may kick in if the TBI is enabled. I do not
      know if the TBI has ever been used in real life.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      4876cc1e
    • F
      r8169: rtl8169_set_speed_xmii cleanup. · 826e6cbd
      Francois Romieu 提交于
      Shorten chipset version test.
      
      No functional change.
      
      Careful readers will notice that the 'supports_gmii' flag is deduced
      from the device PCI id. Though less specific than the chipset related
      RTL_GIGA_MAC_VER_XY, it is good enough to detect a GMII deprieved 810x.
      Some features push for a device specific configuration (improved jumbo
      frame support for instance). 'supports_gmii' will follow this path
      if / when the device PCI id test stops working.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      826e6cbd
    • F
      r8169: remove some code duplication. · 6f43adc8
      Francois Romieu 提交于
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      6f43adc8
    • F
      r8169: style cleanups. · cecb5fd7
      Francois Romieu 提交于
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
      cecb5fd7
  3. 30 4月, 2011 2 次提交
  4. 28 4月, 2011 1 次提交
  5. 24 4月, 2011 1 次提交
  6. 19 4月, 2011 1 次提交
    • F
      r8169: TSO fixes. · 2b7b4318
      Francois Romieu 提交于
      - the MSS value is actually contained in a 11 bits wide (0x7ff) field.
        The extra bit in the former MSSMask did encompass the TSO command
        bit ("LargeSend") as well (0xfff). Oops.
      
      - the Tx descriptor layout is not the same through the whole chipset
        family. The 8169 documentation, the 8168c documentation and Realtek's
        drivers (8.020.00, 1.019.00, 6.014.00) highlight two layouts:
        1. 8169, 8168 up to 8168b (included) and 8101
        2. {8102e, 8168c} and beyond
      
      - notwithstanding the "first descriptor" and "last descriptor" bits, the
        same Tx descriptor content is enforced when a packet consists of several
        descriptors. The chipsets are documented to require it.
      
      Credits go to David Dillow <dave@thedillows.org> for the original patch.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: Realtek <nic_swsd@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b7b4318
  7. 11 4月, 2011 1 次提交
  8. 31 3月, 2011 3 次提交
  9. 21 3月, 2011 1 次提交
  10. 20 3月, 2011 1 次提交
  11. 05 3月, 2011 3 次提交
  12. 04 3月, 2011 1 次提交
  13. 02 3月, 2011 1 次提交
  14. 24 2月, 2011 3 次提交
  15. 18 2月, 2011 1 次提交
  16. 04 2月, 2011 3 次提交
  17. 14 1月, 2011 1 次提交
  18. 11 1月, 2011 1 次提交
  19. 10 1月, 2011 1 次提交
  20. 05 1月, 2011 4 次提交