Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 9月, 2017 7 次提交
  3. 08 9月, 2017 2 次提交
  5. 07 9月, 2017 2 次提交
    • L
      rtlwifi: btcoexist: Fix antenna selection code · 6d622692
      由 Larry Finger 提交于 
      In commit 87d8a9f3 ("rtlwifi: btcoex: call bind to setup btcoex"),
the code turns on a call to exhalbtc_bind_bt_coex_withadapter(). This
routine contains a bug that causes incorrect antenna selection for those
HP laptops with only one antenna and an incorrectly programmed EFUSE.
These boxes are the ones that need the ant_sel module parameter.

Fixes: 87d8a9f3 ("rtlwifi: btcoex: call bind to setup btcoex")
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: Stable <stable@vger.kernel.org> # 4.13+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      6d622692
    • L
      rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723be · a33fcba6
      由 Larry Finger 提交于 
      In commit bcd37f4a ("rtlwifi: btcoex: 23b 2ant: let bt transmit when
hw initialisation done"), there is an additional error when the module
parameter ant_sel is used to select the auxilary antenna. The error is
that the antenna selection is not checked when writing the antenna
selection register.

Fixes: bcd37f4a ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done")
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Cc: Stable <stable@vger.kernel.org> # 4.12+
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      a33fcba6
  7. 05 9月, 2017 1 次提交
    • B
      mac80211_hwsim: Use proper TX power · 9de981f5
      由 Beni Lev 提交于 
      In struct ieee80211_tx_info, control.vif pointer and rate_driver_data[0]
falls on the same place, depending on the union usage.
During the whole TX process, the union is referred to as a control struct,
which holds the vif that is later used in the tx flow, especially in order
to derive the used tx power.
Referring direcly to rate_driver_data[0] and assigning a value to it,
overwrites the vif pointer, hence making all later references irrelevant.
Moreover, rate_driver_data[0] isn't used later in the flow in order to
retrieve the channel that it is pointing to.

Cc: stable@vger.kernel.org
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9de981f5
  9. 01 9月, 2017 3 次提交
    • C
      wl1251: add a missing spin_lock_init() · f581a0dd
      由 Cong Wang 提交于 
      wl1251: add a missing spin_lock_init()

This fixes the following kernel warning:

 [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
 [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: <none>/-1,
 .owner_cpu: 0
 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
 4.12.0-03002-gec979a4-dirty #40
 [ 5668.772796] Hardware name: Nokia RX-51 board
 [ 5668.773071] Workqueue: phy1 wl1251_irq_work
 [ 5668.773345] [<c010c9e4>] (unwind_backtrace) from [<c010a274>]
 (show_stack+0x10/0x14)
 [ 5668.773803] [<c010a274>] (show_stack) from [<c01545a4>]
 (do_raw_spin_lock+0x6c/0xa0)
 [ 5668.774230] [<c01545a4>] (do_raw_spin_lock) from [<c06ca578>]
 (_raw_spin_lock_irqsave+0x10/0x18)
 [ 5668.774658] [<c06ca578>] (_raw_spin_lock_irqsave) from [<c048c010>]
 (wl1251_op_tx+0x38/0x5c)
 [ 5668.775115] [<c048c010>] (wl1251_op_tx) from [<c06a12e8>]
 (ieee80211_tx_frags+0x188/0x1c0)
 [ 5668.775543] [<c06a12e8>] (ieee80211_tx_frags) from [<c06a138c>]
 (__ieee80211_tx+0x6c/0x130)
 [ 5668.775970] [<c06a138c>] (__ieee80211_tx) from [<c06a3dbc>]
 (ieee80211_tx+0xdc/0x104)
 [ 5668.776367] [<c06a3dbc>] (ieee80211_tx) from [<c06a4af0>]
 (__ieee80211_subif_start_xmit+0x454/0x8c8)
 [ 5668.776824] [<c06a4af0>] (__ieee80211_subif_start_xmit) from
 [<c06a4f94>] (ieee80211_subif_start_xmit+0x30/0x2fc)
 [ 5668.777343] [<c06a4f94>] (ieee80211_subif_start_xmit) from
 [<c0578848>] (dev_hard_start_xmit+0x80/0x118)
...

    by adding the missing spin_lock_init().
Reported-by: NPavel Machek <pavel@ucw.cz>
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f581a0dd
    • R
      ath10k: configure and enable the wakeup capability · 393b706c
      由 Ryan Hsu 提交于 
      ACPI will rely on device driver to tell it if the device could support
wakeup function when system in D3 state.

This has caused some platform can't support remote wakeup correctly,
because the ACPI wakeup GPE is not enabled, hence registers the .set_wakeup
callback to handle it if device supports wakeup.

Tested with QCA6174 hw3.0, firmware ('WLAN.RM.4.4.1-00008-QCARMSWP-1')
Signed-off-by: NRyan Hsu <ryanhsu@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      393b706c
    • R
      ath10k: add the PCI PM core suspend/resume ops · 32faa3f0
      由 Ryan Hsu 提交于 
      The actual PCI suspend/resume in ath10k has been handled in wow.c,
but in the case of the device doesn't support remote wakeup,
the .hif_suspend() and .hif_resume() will never be handled.

  ath10k_wow_op_suspend()
  {
	if (WARN_ON(!test_bit(ATH10K_FW_FEATURE_WOWLAN_SUPPORT,
		    ar->running_fw->fw_file.fw_features))) {
		ret = 1;
		goto exit;
	}

	....

	ret = ath10k_hif_suspend(ar);
  }

So register the PCI PM core to support the suspend/resume if the device
doesn't support remote wakeup.
Signed-off-by: NRyan Hsu <ryanhsu@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      32faa3f0
  11. 31 8月, 2017 21 次提交
  13. 30 8月, 2017 3 次提交
  15. 24 8月, 2017 1 次提交
    • L
      iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc() · 10a54d81
      由 Luca Coelho 提交于 
      Work queues cannot be allocated when a mutex is held because the mutex
may be in use and that would make it sleep.  Doing so generates the
following splat with 4.13+:

[   19.513298] ======================================================
[   19.513429] WARNING: possible circular locking dependency detected
[   19.513557] 4.13.0-rc5+ #6 Not tainted
[   19.513638] ------------------------------------------------------
[   19.513767] cpuhp/0/12 is trying to acquire lock:
[   19.513867]  (&tz->lock){+.+.+.}, at: [<ffffffff924afebb>] thermal_zone_get_temp+0x5b/0xb0
[   19.514047]
[   19.514047] but task is already holding lock:
[   19.514166]  (cpuhp_state){+.+.+.}, at: [<ffffffff91cc4baa>] cpuhp_thread_fun+0x3a/0x210
[   19.514338]
[   19.514338] which lock already depends on the new lock.

This lock dependency already existed with previous kernel versions,
but it was not detected until commit 49dfe2a6 ("cpuhotplug: Link
lock stacks for hotplug callbacks") was introduced.
Reported-by: NDavid Weinehall <david.weinehall@intel.com>
Reported-by: NJiri Kosina <jikos@kernel.org>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      10a54d81