1. 26 4月, 2012 2 次提交
  2. 25 4月, 2012 2 次提交
  3. 24 4月, 2012 10 次提交
    • I
      asix: Fix tx transfer padding for full-speed USB · 2a580949
      Ingo van Lil 提交于
      The asix.c USB Ethernet driver avoids ending a tx transfer with a zero-
      length packet by appending a four-byte padding to transfers whose length
      is a multiple of maxpacket. However, the hard-coded 512 byte maxpacket
      length is valid for high-speed USB only; full-speed USB uses 64 byte
      packets.
      Signed-off-by: NIngo van Lil <inguin@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a580949
    • A
      net/davinci_emac: fix failing PHY connect attempts · 1ab8be4a
      Anatolij Gustschin 提交于
      PHY connect attempts fail if no PHY id is specified in the emac platform
      data and another mdio bus has been registered before 'davinci_mdio' bus. In
      this case when configuring the interface, there will be an attempt to
      connect to already attached PHY on the previously registered mdio bus:
      
      net eth1: PHY already attached
      net eth1: could not connect to phy smsc911x-0:01
      IP-Config: Failed to open eth1
      IP-Config: Device `eth1' not found
      
      Fix this by modifying match_first_device() to match first PHY device
      on 'davinci_mdio' bus.
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ab8be4a
    • T
      ehea: only register irq after setting up ports · c2f1244b
      Thadeu Lima de Souza Cascardo 提交于
      If we receive an interrupt too early before we set up ports in the probe
      function, there won't be any port ready to handle it.
      
      Only registering the irq after the ports are setup fixes the problem,
      and works fine without losing any interrupts.
      
      This causes crashes in some situations:
      
      [c000000f7ff7fd60] d000000008e223f0 .ehea_neq_tasklet+0x78/0x148 [ehea]
      [c000000f7ff7fe00] c0000000000b6cac .tasklet_hi_action+0xdc/0x210
      [c000000f7ff7fea0] c0000000000b7cc8 .__do_softirq+0x178/0x300
      [c000000f7ff7ff90] c000000000022694 .call_do_softirq+0x14/0x24
      [c000000f68ee7900] c000000000010e04 .do_softirq+0xec/0x110
      [c000000f68ee79a0] c0000000000b789c .irq_exit+0xac/0xe0
      [c000000f68ee7a20] c0000000000110bc .do_IRQ+0x114/0x2a8
      [c000000f68ee7ae0] c00000000000553c hardware_interrupt_entry+0x18/0x1c
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2f1244b
    • S
      net: usb: smsc95xx: fix mtu · 9bbf5660
      Stephane Fillod 提交于
      Make smsc95xx recalculate the hard_mtu after adjusting the
      hard_header_len.
      
      Without this, usbnet adjusts the MTU down to 1488 bytes, and the host is
      unable to receive standard 1500-byte frames from the device.
      
      Inspired by same fix on cdc_eem 78fb72f7.
      
      Tested on ARM/Beagle.
      Signed-off-by: NStephane Fillod <fillods@users.sf.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9bbf5660
    • E
      brcmsmac: "INTERMEDIATE but not AMPDU" only when tracing · 6ead629b
      Eldad Zack 提交于
      I keep getting the following messages on the log buffer:
      [ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      [ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      [ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      [ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      [ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      [ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      [ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
      
      From the code comment I understand that this something that can -
      and does, quite frequently - happen.
      Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
      Acked-by: Franky Lin<frankyl@broadcom.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6ead629b
    • L
      rtlwifi: Fix oops on unload · 44eb65cf
      Larry Finger 提交于
      Under some circumstances, a PCI-based driver reports the following OOPs:
      
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP
      --snip--
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod
      Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP:
      0010:[<ffffffffa0418d39>]  [<ffffffffa0418d39>]
      rtl92ce_get_desc+0x19/0xd0 [rtl8192ce]
      --snip--
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid:
      19627, threadinfo ffff880050262000, task ffff8801156d5cc0)
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack:
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  0000000000000002
      ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  0000000000000282
      0000000180150014 ffff880050263fd8 ffff8801176c2810
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  ffff880050263bc8
      ffffffff810550e2 00000000000002c0 ffff8801176c0d40
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace:
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  [<ffffffffa03348e7>]
      _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi]
      --snip--
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48
      83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66
      66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1
      e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP
      [<ffffffffa0418d39>] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce]
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011]  RSP <ffff880050263b58>
      Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0
      Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace
      8636c766dcfbe0e6 ]---
      
      This oops is due to interrupts not being disabled in this particular path.
      Reported-by: NDave Airlie <airlied@gmail.com>
      Tested-by: NDave Airlie <airlied@gmail.com>
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      44eb65cf
    • S
      ipw2200: Fix race condition in the command completion acknowledge · dd447319
      Stanislav Yakovlev 提交于
      Driver incorrectly validates command completion: instead of waiting
      for a command to be acknowledged it continues execution.  Most of the
      time driver gets acknowledge of the command completion in a tasklet
      before it executes the next one. But sometimes it sends the next
      command before it gets acknowledge for the previous one. In such a
      case one of the following error messages appear in the log:
      
      Failed to send SYSTEM_CONFIG: Already sending a command.
      Failed to send ASSOCIATE: Already sending a command.
      Failed to send TX_POWER: Already sending a command.
      
      After that you need to reload the driver to get it working again.
      
      This bug occurs during roaming (reported by Sam Varshavchik)
      https://bugzilla.redhat.com/show_bug.cgi?id=738508
      and machine booting (reported by Tom Gundersen and Mads Kiilerich)
      https://bugs.archlinux.org/task/28097
      https://bugzilla.redhat.com/show_bug.cgi?id=802106
      
      This patch doesn't fix the delay issue during firmware load.
      But at least device now works as usual after boot.
      
      Cc: stable@kernel.org
      Signed-off-by: NStanislav Yakovlev <stas.yakovlev@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      dd447319
    • S
      iwlwifi: do not nulify ctx->vif on reset · 8db4c7e2
      Stanislaw Gruszka 提交于
      ctx->vif is dereferenced in different part of iwlwifi code, so do not
      nullify it.
      
      This should address at least one of the possible reasons of WARNING at
      iwlagn_mac_remove_interface, and perhaps some random crashes when
      firmware reset is performed.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8db4c7e2
    • G
      ath9k: fix tx power settings for AR9287 · 83722bd4
      Gabor Juhos 提交于
      The 'ath9k_hw_update_regulatory_maxpower'
      helper function has been introduced by
      commit a55f8588
      (ath9k_hw: Cleanup TX power calculation for AR9287).
      
      Updating of the max_power_level value has been moved
      into the helper function in that change, however the
      removed code from 'ath9k_hw_ar9287_set_txpower' has
      not been replaced with a call of the new helper
      function.
      
      Due to that missing call, retrieving tx power for 2x2
      and 3x3 chainmask is not handled properly. During the
      calculation of the tx power for 2x2 and 3x3 chainmasks
      the values are reduced. Those reductions must be
      compensated during retrieving.
      
      Fix this by adding the missing call of the helper
      function.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Acked-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      83722bd4
    • G
      ath9k: add an extra boolean parameter to ath9k_hw_apply_txpower · 64ea57d0
      Gabor Juhos 提交于
      In order to unifying regulatory limit handling
      commit ca2c68cc
      (ath9k_hw: clean up tx power handling) introduced
      a new helper function 'ath9k_hw_apply_txpower',
      and the direct calls of 'ah->eep_ops->set_txpower'
      has been replaced by a call of the helper function.
      
      This caused a change in the behaviour of the
      'ath9k_hw_set_txpowerlimit' function. The purpose
      of that function is to calculate and store the
      rate txpower table and the regulatory limit without
      touching the hardware registers. Before the commit,
      the 'test' parameter of the function was passed to
      the 'ah->eep_ops->set_txpower'. Now the calling of
      the 'set_txpower' function happens indirectly through
      'ath9k_hw_apply_txpower', so the 'test' argument of
      the 'set_txpower' is always 'false'.
      
      This patch restores the original behaviour of
      'ath9k_hw_set_txpowerlimit' by adding a new
      argument to 'ath9k_hw_apply_txpower.'
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Acked-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      64ea57d0
  4. 22 4月, 2012 4 次提交
    • L
      drivers/net: Do not free an IRQ if its request failed · 163faf31
      Lee Jones 提交于
      Refrain from attempting to free an interrupt line if the request
      fails and hence, there is no IRQ to free.
      
      CC: netdev@vger.kernel.org
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      163faf31
    • M
      ks8851: Fix request_irq/free_irq mismatch · e8195b24
      Matt Renzelmann 提交于
      The dev_id parameter passed to free_irq needs to match the one passed
      to the corresponding request_irq.
      Signed-off-by: NMatt Renzelmann <mjr@cs.wisc.edu>
      Acked-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8195b24
    • W
      net/hyperv: Adding cancellation to ensure rndis filter is closed · 792df872
      Wenqi Ma 提交于
      Although the network interface is down, the RX packets number which
      could be observed by ifconfig may keep on increasing.
      
      This is because the WORK scheduled in netvsc_set_multicast_list()
      may be executed after netvsc_close(). That means the rndis filter
      may be re-enabled by do_set_multicast() even if it was closed by
      netvsc_close().
      
      By canceling possible WORK before close the rndis filter, the issue
      could be never happened.
      Signed-off-by: NWenqi Ma <wenqi_ma@trendmicro.com.cn>
      Reviewed-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      792df872
    • S
      ks8851: Fix mutex deadlock in ks8851_net_stop() · c5a99937
      Stephen Boyd 提交于
      There is a potential deadlock scenario when the ks8851 driver
      is removed. The interrupt handler schedules a workqueue which
      acquires a mutex that ks8851_net_stop() also acquires before
      flushing the workqueue. Previously lockdep wouldn't be able
      to find this problem but now that it has the support we can
      trigger this lockdep warning by rmmoding the driver after
      an ifconfig up.
      
      Fix the possible deadlock by disabling the interrupts in
      the chip and then release the lock across the workqueue
      flushing. The mutex is only there to proect the registers
      anyway so this should be ok.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      3.0.21-00021-g8b33780-dirty #2911
      -------------------------------------------------------
      rmmod/125 is trying to acquire lock:
       ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac
      
      but task is already holding lock:
       (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&ks->lock){+.+...}:
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c083dbec>] mutex_lock_nested+0x68/0x3dc
             [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
             [<c019c580>] process_one_work+0x2d8/0x518
             [<c019cb98>] worker_thread+0x220/0x3a0
             [<c01a2ad4>] kthread+0x88/0x94
             [<c0107008>] kernel_thread_exit+0x0/0x8
      
      -> #0 ((&ks->irq_work)){+.+...}:
             [<c01b7984>] validate_chain+0x914/0x1018
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c019e104>] flush_work+0x4c/0xac
             [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
             [<c06b209c>] __dev_close_many+0x98/0xcc
             [<c06b2174>] dev_close_many+0x68/0xd0
             [<c06b22ec>] rollback_registered_many+0xcc/0x2b8
             [<c06b2554>] rollback_registered+0x28/0x34
             [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
             [<c06b25f4>] unregister_netdev+0x18/0x20
             [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
             [<c049ddf0>] spi_drv_remove+0x18/0x1c
             [<c0468e98>] __device_release_driver+0x7c/0xbc
             [<c0468f64>] driver_detach+0x8c/0xb4
             [<c0467f00>] bus_remove_driver+0xb8/0xe8
             [<c01c1d20>] sys_delete_module+0x1e8/0x27c
             [<c0105ec0>] ret_fast_syscall+0x0/0x3c
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&ks->lock);
                                     lock((&ks->irq_work));
                                     lock(&ks->lock);
        lock((&ks->irq_work));
      
       *** DEADLOCK ***
      
      4 locks held by rmmod/125:
       #0:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
       #1:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
       #2:  (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
       #3:  (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5a99937
  5. 20 4月, 2012 4 次提交
  6. 18 4月, 2012 6 次提交
  7. 17 4月, 2012 3 次提交
  8. 15 4月, 2012 1 次提交
    • D
      net/ethernet: ks8851_mll fix rx frame buffer overflow · 8a9a0ea6
      Davide Ciminaghi 提交于
      At the beginning of ks_rcv(), a for loop retrieves the
      header information relevant to all the frames stored
      in the mac's internal buffers. The number of pending
      frames is stored as an 8 bits field in KS_RXFCTR.
      If interrupts are disabled long enough to allow for more than
      32 frames to accumulate in the MAC's internal buffers, a buffer
      overflow occurs.
      This patch fixes the problem by making the
      driver's frame_head_info buffer big enough.
      Well actually, since the chip appears to have 12K of
      internal rx buffers and the shortest ethernet frame should
      be 64 bytes long, maybe the limit could be set to
      12*1024/64 = 192 frames, but 255 should be safer.
      Signed-off-by: NDavide Ciminaghi <ciminaghi@gnudd.com>
      Signed-off-by: NRaffaele Recalcati <raffaele.recalcati@bticino.it>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a9a0ea6
  9. 14 4月, 2012 8 次提交