1. 13 12月, 2011 2 次提交
  2. 09 12月, 2011 1 次提交
    • H
      ssb: fix init regression with SoCs · 329456d1
      Hauke Mehrtens 提交于
      This fixes a Data bus error on some SoCs. The first fix for this
      problem did not solve it on all devices.
          commit 6ae8ec27
          Author: Rafał Miłecki <zajec5@gmail.com>
          Date:   Tue Jul 5 17:25:32 2011 +0200
              ssb: fix init regression of hostmode PCI core
      
      In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is
      accessed, but the sprom only exists when the ssb bus is connected over
      a PCI bus to the rest of the system and not when the SSB Bus is the
      main system bus. SoCs sometimes have a PCI host controller and there
      this code will not be executed, but there are some old SoCs with an PCI
      controller in client mode around and ssb_pcicore_fix_sprom_core_index()
      should not be called on these devices too. The PCI controller on these
      devices are unused, but without this fix it results in an Data bus
      error when it gets initialized.
      
      Cc: Michael Buesch <m@bues.ch>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      329456d1
  3. 08 12月, 2011 2 次提交
  4. 07 12月, 2011 2 次提交
  5. 03 12月, 2011 5 次提交
    • A
      Bluetooth: Correct version check in hci_setup · 33cb722c
      Andrei Emeltchenko 提交于
      Check for hci_ver instead of lmp_ver
      Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      33cb722c
    • C
      btusb: fix a memory leak in btusb_send_frame() · 54a8a79c
      Cong Wang 提交于
      This patch fixes the following memory leak reported by kmemleak:
      
      unreferenced object 0xffff880060a53840 (size 192):
        comm "softirq", pid 0, jiffies 4320571771 (age 1406.569s)
        hex dump (first 32 bytes):
          01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff81138a1c>] create_object+0x187/0x28b
          [<ffffffff814be12e>] kmemleak_alloc+0x73/0x98
          [<ffffffff811289d3>] __kmalloc+0xfc/0x123
          [<ffffffff81386546>] usb_alloc_urb+0x1e/0x48
          [<ffffffffa0130274>] btusb_send_frame+0x86/0x385 [btusb]
          [<ffffffffa02d8230>] hci_send_frame+0xa0/0xa5 [bluetooth]
          [<ffffffffa02d8a4e>] hci_cmd_task+0xa0/0xfb [bluetooth]
          [<ffffffff81058548>] tasklet_action+0x8f/0xef
          [<ffffffff81058a4c>] __do_softirq+0xf4/0x1db
          [<ffffffff81058bb7>] run_ksoftirqd+0x84/0x129
          [<ffffffff8106f1c4>] kthread+0xa0/0xa8
          [<ffffffff814dd144>] kernel_thread_helper+0x4/0x10
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      The problem is that when inc_tx() returns non-zero, we forgot
      to call usb_free_urb().
      
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: "Gustavo F. Padovan" <padovan@profusion.mobi>
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      54a8a79c
    • W
      iwlwifi: change the default behavior of watchdog timer · 9995ffe5
      Wey-Yi Guy 提交于
      The current default watchdog timer is enabled, but we are seeing issues on
      legacy devices. So change the default setting of watchdog timer to per
      device based. But user still can use the "wd_disable" module parameter
      to overwrite the system setting
      
      Cc: stable@vger.kernel.org #3.0+
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9995ffe5
    • W
      iwlwifi: do not re-configure HT40 after associated · 34a5b4b6
      Wey-Yi Guy 提交于
      The ht40 setting should not change after association unless channel switch
      
      This fix a problem we are seeing which cause uCode assert because driver
      sending invalid information and make uCode confuse
      
      Here is the firmware assert message:
      kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
      kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
      kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
      kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
      kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
      kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
      kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
      kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
      kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
      kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
      kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
      kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
      kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
      kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
      kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
      kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
      kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
      kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
      kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
      kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
      kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
      kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
      kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
      kernel: iwlagn 0000:03:00.0: CSR values:
      kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
      kernel: iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480303
      kernel: iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
      kernel: iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
      kernel: iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
      kernel: iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000030
      kernel: iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
      kernel: iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
      kernel: iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X000000b0
      kernel: iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X07d60ffd
      kernel: iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
      kernel: iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00030001
      kernel: iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080044
      kernel: iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000093bb
      kernel: iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
      kernel: iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000078
      kernel: iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88214dd2
      kernel: iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
      kernel: iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
      kernel: iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0010
      kernel: iwlagn 0000:03:00.0: FH register values:
      kernel: iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
      kernel: iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
      kernel: iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000060
      kernel: iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
      kernel: iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
      kernel: iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
      kernel: iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
      kernel: iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
      kernel: iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
      kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
      kernel: ------------[ cut here ]------------
      WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
      kernel: Hardware name: 4290W4H
      kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
      kernel: Call Trace:
      kernel:  [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
      kernel:  [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
      kernel:  [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
      kernel:  [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
      kernel:  [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
      kernel:  [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
      kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
      kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
      kernel:  [<ffffffff8104ba97>] ? kthread+0x7a/0x82
      kernel:  [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
      kernel:  [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
      kernel:  [<ffffffff813d21b0>] ? gs_change+0xb/0xb
      
      Cc: <stable@kernel.org> 3.1+
      Reported-by: NUdo Steinberg <udo@hypervisor.org>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34a5b4b6
    • J
      iwlagn: fix HW crypto for TX-only keys · 274b89ca
      Johannes Berg 提交于
      Group keys in IBSS or AP mode are not programmed
      into the device since we give the key to it with
      every TX packet. However, we do need mac80211 to
      create the MMIC & PN in all cases. Move the code
      around to set the key flags all the time. We set
      them even when the key is removed again but that
      is obviously harmless.
      
      Cc: stable@vger.kernel.org
      Reported-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      274b89ca
  6. 01 12月, 2011 4 次提交
  7. 29 11月, 2011 6 次提交
    • E
      mac80211: fix race between the AGG SM and the Tx data path · 2a1e0fd1
      Emmanuel Grumbach 提交于
      When a packet is supposed to sent be as an a-MPDU, mac80211 sets
      IEEE80211_TX_CTL_AMPDU to let the driver know. On the other
      hand, mac80211 configures the driver for aggregration with the
      ampdu_action callback.
      There is race between these two mechanisms since the following
      scenario can occur when the BA agreement is torn down:
      
      Tx softIRQ	 			drv configuration
      ==========				=================
      
      check OPERATIONAL bit
      Set the TX_CTL_AMPDU bit in the packet
      
      					clear OPERATIONAL bit
      					stop Tx AGG
      Pass Tx packet to the driver.
      
      In that case the driver would get a packet with TX_CTL_AMPDU set
      although it has already been notified that the BA session has been
      torn down.
      
      To fix this, we need to synchronize all the Qdisc activity after we
      cleared the OPERATIONAL bit. After that step, all the following
      packets will be buffered until the driver reports it is ready to get
      new packets for this RA / TID. This buffering allows not to run into
      another race that would send packets with TX_CTL_AMPDU unset while
      the driver hasn't been requested to tear down the BA session yet.
      
      This race occurs in practice and iwlwifi complains with a WARN_ON
      when it happens.
      
      Cc: stable@kernel.org
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a1e0fd1
    • N
      mac80211: fix race condition caused by late addBA response · d305a655
      Nikolay Martynov 提交于
      If addBA responses comes in just after addba_resp_timer has
      expired mac80211 will still accept it and try to open the
      aggregation session. This causes drivers to be confused and
      in some cases even crash.
      
      This patch fixes the race condition and makes sure that if
      addba_resp_timer has expired addBA response is not longer
      accepted and we do not try to open half-closed session.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNikolay Martynov <mar.kolya@gmail.com>
      [some adjustments]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d305a655
    • R
      ath9k: Revert change that broke AR928X on Acer Ferrari One · a7322812
      Rafael J. Wysocki 提交于
      Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by
      commit 2577c6e8 (ath9k_hw: Add
      support for AR946/8x chipsets) that caused a nasty regression to
      appear on my Acer Ferrari One (the box locks up entirely at random
      times after the wireless has been started without any way to get
      debug information out of it).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7322812
    • S
      rtlwifi: fix lps_lock deadlock · e55b32c1
      Stanislaw Gruszka 提交于
      rtl_lps_leave can be called from interrupt context, so we have to
      disable interrupts when taking lps_lock.
      
      Below is full lockdep info about deadlock:
      
      [   93.815269] =================================
      [   93.815390] [ INFO: inconsistent lock state ]
      [   93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815556] ---------------------------------
      [   93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [   93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [   93.815832]  (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.815947] {SOFTIRQ-ON-W} state was registered at:
      [   93.815947]   [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c
      [   93.815947]   [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.815947]   [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.815947]   [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi]
      [   93.815947]   [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi]
      [   93.815947]   [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211]
      [   93.815947]   [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211]
      [   93.815947]   [<ffffffff81075aa5>] process_one_work+0x205/0x3e7
      [   93.815947]   [<ffffffff81076753>] worker_thread+0xda/0x15d
      [   93.815947]   [<ffffffff8107a119>] kthread+0xa8/0xb0
      [   93.815947]   [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10
      [   93.815947] irq event stamp: 547822
      [   93.815947] hardirqs last  enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61
      [   93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e
      [   93.815947] softirqs last  enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15
      [   93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.815947]
      [   93.815947] other info that might help us debug this:
      [   93.815947]  Possible unsafe locking scenario:
      [   93.815947]
      [   93.815947]        CPU0
      [   93.815947]        ----
      [   93.815947]   lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]   <Interrupt>
      [   93.815947]     lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]
      [   93.815947]  *** DEADLOCK ***
      [   93.815947]
      [   93.815947] no locks held by swapper/0.
      [   93.815947]
      [   93.815947] stack backtrace:
      [   93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815947] Call Trace:
      [   93.815947]  <IRQ>  [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8
      [   93.815947]  [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49
      [   93.815947]  [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0
      [   93.815947]  [<ffffffff8108dc8a>] mark_lock+0x106/0x220
      [   93.815947]  [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c
      [   93.815947]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
      [   93.830125]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
      [   93.830125]  [<ffffffff81080181>] ? sched_clock_local+0x12/0x75
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d
      [   93.830125]  [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi]
      [   93.830125]  [<ffffffff8106281f>] tasklet_action+0x8d/0xee
      [   93.830125]  [<ffffffff810629ce>] __do_softirq+0x112/0x25a
      [   93.830125]  [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.830125]  [<ffffffff81010bf6>] do_softirq+0x4b/0xa1
      [   93.830125]  [<ffffffff81062d7d>] irq_exit+0x5d/0xcf
      [   93.830125]  [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5
      [   93.830125]  [<ffffffff814ea533>] common_interrupt+0x73/0x73
      [   93.830125]  <EOI>  [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf
      [   93.830125]  [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c
      [   93.830125]  [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c
      [   93.830125]  [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe
      [   93.830125]  [<ffffffff8100e2ef>] cpu_idle+0xab/0x101
      [   93.830125]  [<ffffffff814c6373>] rest_init+0xd7/0xde
      [   93.830125]  [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c
      [   93.830125]  [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea
      [   93.830125]  [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3
      [   93.830125]  [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140
      [   93.830125]  [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111
      
      Resolves:
      https://bugzilla.redhat.com/show_bug.cgi?id=755154
      
      Reported-by: vjain02@students.poly.edu
      Reported-and-tested-by: NOliver Paukstadt <pstadt@sourcentral.org>
      Cc: stable@vger.kernel.org
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e55b32c1
    • J
      mac80211: don't stop a single aggregation session twice · 24f50a9d
      Johannes Berg 提交于
      Nikolay noticed (by code review) that mac80211 can
      attempt to stop an aggregation session while it is
      already being stopped. So to fix it, check whether
      stop is already being done and bail out if so.
      
      Also move setting the STOPPING state into the lock
      so things are properly atomic.
      
      Cc: stable@vger.kernel.org
      Reported-by: NNikolay Martynov <mar.kolya@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      24f50a9d
    • E
      nl80211: fix MAC address validation · e007b857
      Eliad Peller 提交于
      MAC addresses have a fixed length. The current
      policy allows passing < ETH_ALEN bytes, which
      might result in reading beyond the buffer.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e007b857
  8. 23 11月, 2011 2 次提交
  9. 22 11月, 2011 6 次提交
  10. 21 11月, 2011 1 次提交
  11. 18 11月, 2011 5 次提交
  12. 15 11月, 2011 3 次提交
  13. 12 11月, 2011 1 次提交