1. 11 8月, 2011 1 次提交
  2. 04 8月, 2011 1 次提交
  3. 13 7月, 2011 1 次提交
  4. 28 6月, 2011 1 次提交
  5. 10 6月, 2011 4 次提交
    • B
      b3ccf267
    • B
      e1000e: access multiple PHY registers on same page at the same time · 2b6b168d
      Bruce Allan 提交于
      Doing a PHY page select can take a long time, relatively speaking. This
      can cause a significant delay when updating a number of PHY registers on
      the same page by unnecessarily setting the page for each PHY access. For
      example when going to Sx, all the PHY wakeup registers (WUC, RAR[], MTA[],
      SHRAR[], IP4AT[], IP6AT[], etc.) on 82577/8/9 need to be updated which
      takes a long time which can cause issues when suspending.
      
      This patch introduces new PHY ops function pointers to allow callers to
      set the page directly and do any number of PHY accesses on that page.
      This feature is currently only implemented for 82577, 82578 and 82579
      PHYs for both the normally addressed registers as well as the special-
      case addressing of the PHY wakeup registers on page 800. For the latter
      registers, the existing function for accessing the wakeup registers has
      been divided up into three- 1) enable access to the wakeup register page,
      2) perform the register access and 3) disable access to the wakeup register
      page. The two functions that enable/disable access to the wakeup register
      page are necessarily available to the caller so that the caller can restore
      the value of the Port Control (a.k.a. Wakeup Enable) register after the
      wakeup register accesses are done.
      
      All instances of writing to multiple PHY registers on the same page are
      updated to use this new method and to acquire any PHY locking mechanism
      before setting the page and performing the register accesses, and release
      the locking mechanism afterward.
      
      Some affiliated magic number cleanup is done as well.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2b6b168d
    • B
      e1000e: do not schedule the Tx queue until ready · 400484fa
      Bruce Allan 提交于
      Start the Tx queue when the interface is brought up in e1000e_up() but do
      not schedule the queue until link is up as detected in the watchdog task
      which sets netif_carrier_on.
      
      Also flush the descriptors and clean the Tx and Rx rings before resetting
      the hardware when bringing the interface down otherwise there is a small
      window where the watchdog task can be triggered with netif_carrier_off
      and the Tx ring not yet empty which causes an additional and unnecessary
      reset.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      400484fa
    • B
      e1000e: 82579 intermittently disabled during S0->Sx · 99730e4c
      Bruce Allan 提交于
      When repeatedly cycling Sx->S0 states with the network cable unplugged,
      the 82579 PHY may not initialize as expected and may require a full power
      cycle to recover functionality to the device.  Workaround this by testing
      access of the PHY registers after resuming; if that returns unexpected
      results toggle the LANPHYPC signal to power cycle the PHY.
      
      This is implemented in the new function e1000_resume_workarounds_pchlan()
      which calls another new function, e1000_toggle_lanphypc_value_ich8lan(),
      which has been created to reduce code duplication (same functionality
      required by a previous workaround).  Also, e1000e_disable_gig_wol_ich8lan
      is now e1000_suspend_workarounds_ich8lan to better reflect what it does.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      99730e4c
  6. 07 6月, 2011 1 次提交
  7. 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
  8. 22 5月, 2011 1 次提交
    • Y
      PCI/e1000e: Add and use pci_disable_link_state_locked() · 9f728f53
      Yinghai Lu 提交于
      Need to use it in _e1000e_disable_aspm.  This routine is used for error
      recovery, where the pci_bus_sem is already held, and we don't want
      pci_disable_link_state to try to take it again.  So add a locked variant
      for use in cases like this.
      
      Found lock up:
      
      [ 2374.654557] kworker/32:1    D ffff881027f6b0f0     0  6075      2 0x00000000
      [ 2374.654816]  ffff88503f099a68 0000000000000046 ffff88503f098000 0000000000004000
      [ 2374.654837]  00000000001d1ec0 ffff88503f099fd8 00000000001d1ec0 ffff88503f099fd8
      [ 2374.654860]  0000000000004000 00000000001d1ec0 ffff88503dcc8000 ffff88503f090000
      [ 2374.654880] Call Trace:
      [ 2374.654898]  [<ffffffff810b1302>] ? __lock_acquired+0x3a/0x224
      [ 2374.654914]  [<ffffffff81c2b59c>] ? _raw_spin_unlock_irq+0x30/0x36
      [ 2374.654925]  [<ffffffff810b069d>] ? trace_hardirqs_on_caller+0x1f/0x178
      [ 2374.654936]  [<ffffffff81c2ab24>] rwsem_down_failed_common+0xd3/0x103
      [ 2374.654945]  [<ffffffff810b158f>] ? __lock_contended+0x3a/0x2a2
      [ 2374.654955]  [<ffffffff81c2ab7b>] rwsem_down_read_failed+0x12/0x14
      [ 2374.654967]  [<ffffffff813371e4>] call_rwsem_down_read_failed+0x14/0x30
      [ 2374.654981]  [<ffffffff8135df20>] ? pci_disable_link_state+0x5f/0xf5
      [ 2374.654990]  [<ffffffff81c2a0e6>] ? down_read+0x7e/0x91
      [ 2374.654999]  [<ffffffff8135df20>] ? pci_disable_link_state+0x5f/0xf5
      [ 2374.655008]  [<ffffffff8135df20>] pci_disable_link_state+0x5f/0xf5
      [ 2374.655024]  [<ffffffff81661796>] e1000e_disable_aspm+0x55/0x5a
      [ 2374.655037]  [<ffffffff816677eb>] e1000_io_slot_reset+0x59/0xea
      [ 2374.655048]  [<ffffffff8135fe0d>] ? report_mmio_enabled+0x5d/0x5d
      [ 2374.655057]  [<ffffffff8135fe3b>] report_slot_reset+0x2e/0x5d
      [ 2374.655072]  [<ffffffff8135369e>] pci_walk_bus+0x8a/0xb7
      [ 2374.655081]  [<ffffffff8135fe0d>] ? report_mmio_enabled+0x5d/0x5d
      [ 2374.655091]  [<ffffffff813603be>] broadcast_error_message+0xa4/0xb2
      [ 2374.655101]  [<ffffffff81352c71>] ? pci_bus_read_config_dword+0x72/0x80
      [ 2374.655110]  [<ffffffff813606df>] do_recovery+0x9e/0xf9
      [ 2374.655120]  [<ffffffff81360786>] handle_error_source+0x4c/0x51
      [ 2374.655129]  [<ffffffff81360974>] aer_isr_one_error+0x1e9/0x21a
      [ 2374.655138]  [<ffffffff81360a6c>] aer_isr+0xc7/0xcc
      [ 2374.655147]  [<ffffffff813609a5>] ? aer_isr_one_error+0x21a/0x21a
      [ 2374.655159]  [<ffffffff81096d9f>] process_one_work+0x237/0x3ec
      [ 2374.655168]  [<ffffffff81096d10>] ? process_one_work+0x1a8/0x3ec
      [ 2374.655178]  [<ffffffff8109728d>] worker_thread+0x17c/0x240
      [ 2374.655186]  [<ffffffff810b0803>] ? trace_hardirqs_on+0xd/0xf
      [ 2374.655196]  [<ffffffff81097111>] ? manage_workers+0xab/0xab
      [ 2374.655209]  [<ffffffff8109c8ed>] kthread+0xa0/0xa8
      [ 2374.655223]  [<ffffffff81c332d4>] kernel_thread_helper+0x4/0x10
      [ 2374.655232]  [<ffffffff81c2b880>] ? retint_restore_args+0xe/0xe
      [ 2374.655243]  [<ffffffff8109c84d>] ? __init_kthread_worker+0x5b/0x5b
      [ 2374.655252]  [<ffffffff81c332d0>] ? gs_change+0xb/0xb
      
      when aer happens,
      pci_walk_bus already have down_read(&pci_bus_sem)...
      then report_slot_reset
              ==> e1000_io_slot_reset
                      ==> e1000e_disable_aspm
                              ==> pci_disable_link_state...
      
      We can not use pci_disable_link_state, and it will try to hold pci_bus_sem again.
      
      Try to have __pci_disable_link_state that will not need to hold pci_bus_sem.
      
      -v2: change name to pci_disable_link_state_locked() according to Jesse.
      
      [jbarnes: make sure new function is exported for modules]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      9f728f53
  9. 27 4月, 2011 1 次提交
  10. 14 4月, 2011 5 次提交
  11. 31 3月, 2011 1 次提交
  12. 15 3月, 2011 1 次提交
  13. 11 3月, 2011 2 次提交
  14. 02 3月, 2011 1 次提交
  15. 17 2月, 2011 2 次提交
  16. 12 2月, 2011 1 次提交
  17. 08 2月, 2011 1 次提交
  18. 24 1月, 2011 2 次提交
  19. 14 1月, 2011 2 次提交
  20. 10 1月, 2011 3 次提交
  21. 25 12月, 2010 2 次提交
  22. 17 12月, 2010 1 次提交
  23. 12 12月, 2010 1 次提交
    • T
      drivers/net: don't use flush_scheduled_work() · 23f333a2
      Tejun Heo 提交于
      flush_scheduled_work() is on its way out.  This patch contains simple
      conversions to replace flush_scheduled_work() usage with direct
      cancels and flushes.
      
      Directly cancel the used works on driver detach and flush them in
      other cases.
      
      The conversions are mostly straight forward and the only dangers are,
      
      * Forgetting to cancel/flush one or more used works.
      
      * Cancelling when a work should be flushed (ie. the work must be
        executed once scheduled whether the driver is detaching or not).
      
      I've gone over the changes multiple times but it would be much
      appreciated if you can review with the above points in mind.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jay Cliburn <jcliburn@gmail.com>
      Cc: Michael Chan <mchan@broadcom.com>
      Cc: Divy Le Ray <divy@chelsio.com>
      Cc: e1000-devel@lists.sourceforge.net
      Cc: Vasanthy Kolluri <vkolluri@cisco.com>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: Lennert Buytenhek <buytenh@wantstofly.org>
      Cc: Andrew Gallatin <gallatin@myri.com>
      Cc: Francois Romieu <romieu@fr.zoreil.com>
      Cc: Ramkrishna Vepa <ramkrishna.vepa@exar.com>
      Cc: Matt Carlson <mcarlson@broadcom.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
      Cc: netdev@vger.kernel.org
      23f333a2
  24. 11 12月, 2010 2 次提交