1. 04 1月, 2012 1 次提交
  2. 20 12月, 2011 1 次提交
  3. 06 12月, 2011 2 次提交
    • F
      r8169: fix Rx index race between FIFO overflow recovery and NAPI handler. · c7c2c39b
      françois romieu 提交于
      Since 92fc43b4, rtl8169_tx_timeout ends up
      resetting Rx and Tx indexes and thus racing with the NAPI handler via
      -> rtl8169_hw_reset
         -> rtl_hw_reset
            -> rtl8169_init_ring_indexes
      
      What about returning to the original state ?
      
      rtl_hw_reset is only used by rtl8169_hw_reset and rtl8169_init_one.
      
      The latter does not need rtl8169_init_ring_indexes because the indexes
      still contain their original values from the newly allocated network
      device private data area (i.e. 0).
      
      rtl8169_hw_reset is used by:
      1. rtl8169_down
         Helper for rtl8169_close. rtl8169_open explicitely inits the indexes
         anyway.
      2. rtl8169_pcierr_interrupt
         Indexes are set by rtl8169_reinit_task.
      3. rtl8169_interrupt
         rtl8169_hw_reset is needed when the device goes down. See 1.
      4. rtl_shutdown
         System shutdown handler. Indexes are irrelevant.
      5. rtl8169_reset_task
         Indexes must be set before rtl_hw_start is called.
      6. rtl8169_tx_timeout
         Indexes should not be set. This is the job of rtl8169_reset_task anyway.
      
      The removal of rtl8169_hw_reset in rtl8169_tx_timeout and its move in
      rtl8169_reset_task do not change the analysis.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: hayeswang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7c2c39b
    • F
      r8169: Rx FIFO overflow fixes. · 811fd301
      françois romieu 提交于
      Realtek has specified that the post 8168c gigabit chips and the post
      8105e fast ethernet chips recover automatically from a Rx FIFO overflow.
      The driver does not need to clear the RxFIFOOver bit of IntrStatus and
      it should rather avoid messing it.
      
      The implementation deserves some explanation:
      1. events outside of the intr_event bit mask are now ignored. It enforces
         a no-processing policy for the events that either should not be there
         or should be ignored.
      
      2. RxFIFOOver was already ignored in rtl_cfg_infos[RTL_CFG_1] for the
         whole 8168 line of chips with two exceptions:
         - RTL_GIGA_MAC_VER_22 since b5ba6d12
           ("use RxFIFO overflow workaround for 8168c chipset.").
           This one should now be correctly handled.
         - RTL_GIGA_MAC_VER_11 (8168b) which requires a different Rx FIFO
           overflow processing.
      
         Though it does not conform to Realtek suggestion above, the updated
         driver includes no change for RTL_GIGA_MAC_VER_12 and RTL_GIGA_MAC_VER_17.
         Both are 8168b. RTL_GIGA_MAC_VER_12 is common and a bit old so I'd rather
         wait for experimental evidence that the change suggested by Realtek really
         helps or does not hurt in unexpected ways.
      
         Removed case statements in rtl8169_interrupt are only 8168 relevant.
      
      3. RxFIFOOver is masked for post 8105e 810x chips, namely the sole 8105e
         (RTL_GIGA_MAC_VER_30) itself.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: hayeswang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      811fd301
  4. 29 11月, 2011 1 次提交
  5. 17 11月, 2011 2 次提交
  6. 09 11月, 2011 2 次提交
  7. 02 11月, 2011 1 次提交
  8. 19 10月, 2011 1 次提交
  9. 08 10月, 2011 1 次提交
  10. 04 10月, 2011 1 次提交
  11. 22 9月, 2011 4 次提交
  12. 16 9月, 2011 2 次提交
  13. 31 8月, 2011 1 次提交
  14. 27 8月, 2011 1 次提交
    • J
      drivers/net/ethernet/*: Enabled vendor Kconfig options · 88f07484
      Jeff Kirsher 提交于
      Based on finds for Stephen Rothwell, where current defconfig's
      enable a ethernet driver and it is not compiled due to the newly
      added NET_VENDOR_* component of Kconfig.
      
      This patch enables all the "new" Kconfig options so that current
      defconfig's will continue to compile the expected drivers.  In
      addition, by enabling all the new Kconfig options does not add
      any un-expected options.
      
      CC: Stephen Rothwll <sfc@canb.auug.org.au>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      88f07484
  15. 18 8月, 2011 1 次提交
  16. 12 8月, 2011 1 次提交