1. 18 8月, 2011 1 次提交
  2. 11 8月, 2011 1 次提交
    • J
      broadcom: Move the Broadcom drivers · adfc5217
      Jeff Kirsher 提交于
      Moves the drivers for Broadcom devices into
      drivers/net/ethernet/broadcom/ and the necessary Kconfig and Makefile
      changes.
      
      CC: Eilon Greenstein <eilong@broadcom.com>
      CC: Michael Chan <mchan@broadcom.com>
      CC: Matt Carlson <mcarlson@broadcom.com>
      CC: Gary Zambrano <zambrano@broadcom.com>
      CC: "Maciej W. Rozycki" <macro@linux-mips.org>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      adfc5217
  3. 22 7月, 2011 1 次提交
  4. 17 7月, 2011 1 次提交
    • M
      bnx2: Close device if tx_timeout reset fails · cd634019
      Michael Chan 提交于
      Based on original patch and description from Flavio Leitner <fbl@redhat.com>
      
      When bnx2_reset_task() is called, it will stop,
      (re)initialize and start the interface to restore
      the working condition.
      
      The bnx2_init_nic() calls bnx2_reset_nic() which will
      reset the chip and then calls bnx2_free_skbs() to free
      all the skbs.
      
      The problem happens when bnx2_init_chip() fails because
      bnx2_reset_nic() will just return skipping the ring
      initializations at bnx2_init_all_rings(). Later, the
      reset task starts the interface again and the system
      crashes due a NULL pointer access (no skb in the ring).
      
      To fix it, we call dev_close() if bnx2_init_nic() fails.
      One minor wrinkle to deal with is the cancel_work_sync()
      call in bnx2_close() to cancel bnx2_reset_task().  The
      call will wait forever because it is trying to cancel
      itself and the workqueue will be stuck.
      
      Since bnx2_reset_task() holds the rtnl_lock() and checks
      for netif_running() before proceeding, there is no need
      to cancel bnx2_reset_task() in bnx2_close() even if
      bnx2_close() and bnx2_reset_task() are running concurrently.
      The rtnl_lock() serializes the 2 calls.
      
      We need to move the cancel_work_sync() call to
      bnx2_remove_one() to make sure it is canceled before freeing
      the netdev struct.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
      Cc: Flavio Leitner <fbl@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd634019
  5. 14 7月, 2011 2 次提交
  6. 28 6月, 2011 1 次提交
  7. 09 6月, 2011 1 次提交
  8. 30 4月, 2011 3 次提交
    • D
      ethtool: cosmetic: Use ethtool ethtool_cmd_speed API · 70739497
      David Decotigny 提交于
      This updates the network drivers so that they don't access the
      ethtool_cmd::speed field directly, but use ethtool_cmd_speed()
      instead.
      
      For most of the drivers, these changes are purely cosmetic and don't
      fix any problem, such as for those 1GbE/10GbE drivers that indirectly
      call their own ethtool get_settings()/mii_ethtool_gset(). The changes
      are meant to enforce code consistency and provide robustness with
      future larger throughputs, at the expense of a few CPU cycles for each
      ethtool operation.
      
      All drivers compiled with make allyesconfig ion x86_64 have been
      updated.
      
      Tested: make allyesconfig on x86_64 + e1000e/bnx2x work
      Signed-off-by: NDavid Decotigny <decot@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70739497
    • D
      ethtool: Use full 32 bit speed range in ethtool's set_settings · 25db0338
      David Decotigny 提交于
      This makes sure the ethtool's set_settings() callback of network
      drivers don't ignore the 16 most significant bits when ethtool calls
      their set_settings().
      
      All drivers compiled with make allyesconfig on x86_64 have been
      updated.
      Signed-off-by: NDavid Decotigny <decot@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25db0338
    • N
      bnx2: cancel timer on device removal · 8333a46a
      Neil Horman 提交于
      This oops was recently reported to me:
      
      invalid opcode: 0000 [#1] SMP
      last sysfs file:
      /sys/devices/pci0000:00/0000:00:01.0/0000:01:0d.0/0000:02:05.0/device
      CPU 1
      Modules linked in: bnx2(+) sunrpc ipv6 dm_mirror dm_region_hash dm_log sg
      microcode serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_piix4
      shpchp ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core
      dm_mod [last unloaded: bnx2]
      
      Modules linked in: bnx2(+) sunrpc ipv6 dm_mirror dm_region_hash dm_log sg
      microcode serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_piix4
      shpchp ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core
      dm_mod [last unloaded: bnx2]
      Pid: 23900, comm: pidof Not tainted 2.6.32-130.el6.x86_64 #1 BladeCenter LS21
      -[797251Z]-
      RIP: 0010:[<ffffffffa058b270>]  [<ffffffffa058b270>] 0xffffffffa058b270
      RSP: 0018:ffff880002083e48  EFLAGS: 00010246
      RAX: ffff880002083e90 RBX: ffff88007ccd4000 RCX: 0000000000000000
      RDX: 0000000000000100 RSI: dead000000200200 RDI: ffff8800007b8700
      RBP: ffff880002083ed0 R08: ffff88000208db40 R09: 0000022d191d27c8
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800007b9bc8
      R13: ffff880002083e90 R14: ffff8800007b8700 R15: ffffffffa058b270
      FS:  00007fbb3bcf7700(0000) GS:ffff880002080000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000001664a98 CR3: 0000000060395000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process pidof (pid: 23900, threadinfo ffff8800007e8000, task ffff8800091c0040)
      Stack:
       ffffffff81079f77 ffffffff8109e010 ffff88007ccd5c20 ffff88007ccd5820
      <0> ffff88007ccd5420 ffff8800007e9fd8 ffff8800007e9fd8 0000010000000000
      <0> ffff88007ccd5020 ffff880002083e90 ffff880002083e90 ffffffff8102a00d
      Call Trace:
       <IRQ>
       [<ffffffff81079f77>] ? run_timer_softirq+0x197/0x340
       [<ffffffff8109e010>] ? tick_sched_timer+0x0/0xc0
       [<ffffffff8102a00d>] ? lapic_next_event+0x1d/0x30
       [<ffffffff8106f737>] __do_softirq+0xb7/0x1e0
       [<ffffffff81092cc0>] ? hrtimer_interrupt+0x140/0x250
       [<ffffffff81185f90>] ? filldir+0x0/0xe0
       [<ffffffff8100c2cc>] call_softirq+0x1c/0x30
       [<ffffffff8100df05>] do_softirq+0x65/0xa0
       [<ffffffff8106f525>] irq_exit+0x85/0x90
       [<ffffffff814e3340>] smp_apic_timer_interrupt+0x70/0x9b
       [<ffffffff8100bc93>] apic_timer_interrupt+0x13/0x20
       <EOI>
       [<ffffffff81211ba5>] ? selinux_file_permission+0x45/0x150
       [<ffffffff81262a75>] ? _atomic_dec_and_lock+0x55/0x80
       [<ffffffff812050c6>] security_file_permission+0x16/0x20
       [<ffffffff811861c1>] vfs_readdir+0x71/0xe0
       [<ffffffff81186399>] sys_getdents+0x89/0xf0
       [<ffffffff8100b172>] system_call_fastpath+0x16/0x1b
      
      It occured during some stress testing, in which the reporter was repeatedly
      removing and modprobing the bnx2 module while doing various other random
      operations on the bnx2 registered net device.  Noting that this error occured on
      a serdes based device, we noted that there were a few ethtool operations (most
      notably self_test and set_phys_id) that have execution paths that lead into
      bnx2_setup_serdes_phy.  This function is notable because it executes a mod_timer
      call, which starts the bp->timer running.  Currently bnx2 is setup to assume
      that this timer only nees to be stopped when bnx2_close or bnx2_suspend is
      called.  Since the above ethtool operations are not gated on the net device
      having been opened however, that assumption is incorrect, and can lead to the
      timer still running after the module has been removed, leading to the oops above
      (as well as other simmilar oopses).
      
      Fix the problem by ensuring that the timer is stopped when pci_device_unregister
      is called.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reported-by: NHushan Jia <hjia@redhat.com>
      CC: Michael Chan <mchan@broadcom.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Acked-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8333a46a
  9. 15 4月, 2011 1 次提交
    • A
      ethtool: allow custom interval for physical identification · fce55922
      Allan, Bruce W 提交于
      When physical identification of an adapter is done by toggling the
      mechanism on and off through software utilizing the set_phys_id operation,
      it is done with a fixed duration for both on and off states.  Some drivers
      may want to set a custom duration for the on/off intervals.  This patch
      changes the API so the return code from the driver's entry point when it
      is called with ETHTOOL_ID_ACTIVE can specify the frequency at which to
      cycle the on/off states, and updates the drivers that have already been
      converted to use the new set_phys_id and use the synchronous method for
      identifying an adapter.
      
      The physical identification frequency set in the updated drivers is based
      on how it was done prior to the introduction of set_phys_id.
      
      Compile tested only.  Also fixes a compiler warning in sfc.
      
      v2: drivers do not return -EINVAL for ETHOOL_ID_ACTIVE
      v3: fold patchset into single patch and cleanup per Ben's feedback
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Cc: Sathya Perla <sathya.perla@emulex.com>
      Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
      Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
      Cc: Michael Chan <mchan@broadcom.com>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Cc: Divy Le Ray <divy@chelsio.com>
      Cc: Don Fry <pcnet32@frontier.com>
      Cc: Jon Mason <jdmason@kudzu.us>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Steve Hodgson <shodgson@solarflare.com>
      Cc: Stephen Hemminger <shemminger@linux-foundation.org>
      Cc: Matt Carlson <mcarlson@broadcom.com>
      Acked-by: NJon Mason <jdmason@kudzu.us>
      Acked-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fce55922
  10. 11 4月, 2011 1 次提交
  11. 07 4月, 2011 1 次提交
  12. 29 3月, 2011 1 次提交
  13. 15 3月, 2011 1 次提交
  14. 28 1月, 2011 1 次提交
  15. 27 1月, 2011 1 次提交
  16. 25 1月, 2011 2 次提交
  17. 01 1月, 2011 2 次提交
  18. 22 12月, 2010 1 次提交
  19. 21 12月, 2010 1 次提交
  20. 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
  21. 29 11月, 2010 2 次提交
  22. 28 11月, 2010 1 次提交
  23. 22 10月, 2010 1 次提交
  24. 21 10月, 2010 2 次提交
  25. 12 10月, 2010 2 次提交
  26. 28 9月, 2010 1 次提交
  27. 27 9月, 2010 1 次提交
  28. 03 9月, 2010 1 次提交
  29. 23 8月, 2010 1 次提交
  30. 20 7月, 2010 3 次提交