1. 10 1月, 2011 2 次提交
  2. 25 12月, 2010 2 次提交
  3. 17 12月, 2010 1 次提交
  4. 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
  5. 11 12月, 2010 5 次提交
  6. 28 11月, 2010 1 次提交
  7. 17 11月, 2010 1 次提交
  8. 16 11月, 2010 1 次提交
  9. 29 10月, 2010 2 次提交
  10. 21 10月, 2010 2 次提交
  11. 01 10月, 2010 2 次提交
  12. 27 9月, 2010 1 次提交
  13. 23 9月, 2010 2 次提交
  14. 15 9月, 2010 1 次提交
  15. 03 9月, 2010 1 次提交
  16. 26 8月, 2010 1 次提交
  17. 09 8月, 2010 1 次提交
    • J
      e100/e1000*/igb*/ixgb*: Add missing read memory barrier · 2d0bb1c1
      Jeff Kirsher 提交于
      Based on patches from Sonny Rao and Milton Miller...
      
      Combined the patches to fix up clean_tx_irq and clean_rx_irq.
      
      The PowerPC architecture does not require loads to independent bytes
      to be ordered without adding an explicit barrier.
      
      In ixgbe_clean_rx_irq we load the status bit then load the packet data.
      With packet split disabled if these loads go out of order we get a
      stale packet, but we will notice the bad sequence numbers and drop it.
      
      The problem occurs with packet split enabled where the TCP/IP header
      and data are in different descriptors. If the reads go out of order
      we may have data that doesn't match the TCP/IP header. Since we use
      hardware checksumming this bad data is never verified and it makes it
      all the way to the application.
      
      This bug was found during stress testing and adding this barrier has
      been shown to fix it.  The bug can manifest as a data integrity issue
      (bad payload data) or as a BUG in skb_pull().
      
      This was a nasty bug to hunt down, if people agree with the fix I think
      it's a candidate for stable.
      
      Previously Submitted to e1000-devel only for ixgbe
      
      http://marc.info/?l=e1000-devel&m=126593062701537&w=3
      
      We've now seen this problem hit with other device drivers (e1000e mostly)
      So I'm resubmitting with fixes for other Intel Device Drivers with
      similar issues.
      
      CC: Milton Miller <miltonm@bga.com>
      CC: Anton Blanchard <anton@samba.org>
      CC: Sonny Rao <sonnyrao@us.ibm.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d0bb1c1
  18. 03 8月, 2010 2 次提交
    • J
      e1000e: Fix irq_synchronize in MSI-X case · 8e86acd7
      Jeff Kirsher 提交于
      Based on original patch/work from Jean Delvare <jdelvare@suse.de>
      Synchronize all IRQs when in MSI-X IRQ mode.
      
      Jean's original patch hard coded the sync with the 3 possible vectors,
      this patch incorporates more flexibility for the future and aligns
      with how igb stores the number of vectors into the adapter structure.
      
      CC: Jean Delvare <jdelvare@suse.de>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Acked-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e86acd7
    • F
      e1000e: register pm_qos request on hardware activation · c128ec29
      Florian Mickler 提交于
      The pm_qos_add_request call has to register the pm_qos request with the pm_qos
      susbsystem before first use of the pm_qos request via
      pm_qos_update_request.
      
      As pm_qos changed to use plists there is no benefit in registering and
      unregistering the pm_qos request on ifup/ifdown and thus we move the
      registering into e1000_open and the unregistering in e1000_close.
      
      This fixes the following warning:
      
      [    1.786060] WARNING: at kernel/pm_qos_params.c:264
      pm_qos_update_request+0x28/0x54()
      [    1.786088] Hardware name: Latitude E6500
      [    1.787045] pm_qos_update_request() called for unknown object
      [    1.787966] Modules linked in:
      [    1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
      [    1.790035] Call Trace:
      [    1.791121]  [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
      [    1.792205]  [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
      [    1.793279]  [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
      [    1.794347]  [<ffffffff8134889e>] e1000_configure+0x421/0x459
      [    1.795393]  [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
      [    1.796436]  [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
      [    1.797491]  [<ffffffff8145f948>] __dev_open+0xae/0xe2
      [    1.798547]  [<ffffffff8145f997>] dev_open+0x1b/0x49
      [    1.799612]  [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
      [    1.800685]  [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
      [    1.801744]  [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
      [    1.802793]  [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
      [    1.803845]  [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
      [    1.804885]  [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
      [    1.805915]  [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
      [    1.806937]  [<ffffffff81590e00>] ? restore_args+0x0/0x30
      [    1.807955]  [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
      [    1.808958]  [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
      [    1.809958] ---[ end trace 84b562a00a60539e ]---
      Signed-off-by: NFlorian Mickler <florian@mickler.org>
      Tested-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c128ec29
  19. 31 7月, 2010 1 次提交
    • A
      PCI: change device runtime PM settings for probe and remove · f3ec4f87
      Alan Stern 提交于
      This patch (as1388) changes the way the PCI core handles runtime PM
      settings when probing or unbinding drivers.  Now the core will make
      sure the device is enabled for runtime PM, with a usage count >= 1,
      when a driver is probed.  It does the same when calling a driver's
      remove method.
      
      If the driver wants to use runtime PM, all it has to do is call
      pm_runtime_pu_noidle() near the end of its probe routine (to cancel
      the core's usage increment) and pm_runtime_get_noresume() near the
      start of its remove routine (to restore the usage count).  It does not
      need to mess around with setting the runtime state to enabled,
      disabled, active, or suspended.
      
      The patch updates e1000e and r8169, the only PCI drivers that already
      use the existing runtime PM interface.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f3ec4f87
  20. 27 7月, 2010 1 次提交
  21. 19 7月, 2010 1 次提交
  22. 30 6月, 2010 2 次提交
    • B
      e1000e: suppress compile warnings on certain archs · 8eb64e6b
      Bruce Allan 提交于
      Commit 84f4ee90 causes compile warnings on
      architectures that have unsigned long long's that are not 64-bit, e.g.
      ia64.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8eb64e6b
    • D
      e1000e: don't inadvertently re-set INTX_DISABLE · 36f2407f
      Dean Nelson 提交于
      Should e1000_test_msi() fail to see an msi interrupt, it attempts to
      fallback to legacy INTx interrupts. But an error in the code may prevent
      this from happening correctly.
      
      Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR
      by clearing the SERR bit from the just read PCI_COMMAND bits as it writes
      them back out.
      
      Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR
      by writing out the version of PCI_COMMAND it had previously read.
      
      The problem with this is that e1000_test_msi_interrupt() calls
      pci_disable_msi(), which eventually ends up in pci_intx(). And because
      pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets
      cleared from PCI_COMMAND, which is what we want. But when we get back to
      e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because
      of the attempt by e1000_test_msi() to re-enable SERR.
      
      The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
      part of its attempt to re-enable SERR.
      
      During debugging/testing of this issue I found that not all the systems
      I ran on had the SERR bit set to begin with. And on some of the systems
      the same could be said for the INTX_DISABLE bit. Needless to say these
      latter systems didn't have a problem falling back to legacy INTx
      interrupts with the code as is.
      Signed-off-by: NDean Nelson <dnelson@redhat.com>
      CC: stable@kernel.org
      Tested-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36f2407f
  23. 24 6月, 2010 3 次提交
  24. 19 6月, 2010 3 次提交