From f75c3fae13dc0d9aa6f0ac6a6004bc9e9cc45133 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 6 Jan 2017 13:36:36 +0100 Subject: [PATCH] 4.9-stable patches added patches: arm64-tegra-add-vdd_gpu-regulator-to-jetson-tx1.patch ath10k-fix-soft-lockup-during-firmware-crash-hw-restart.patch ath9k-do-not-return-early-to-fix-rcu-unlocking.patch ath9k-fix-ath9k_hw_gpio_get-to-return-0-or-1-on-success.patch ath9k-really-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch cfg80211-mac80211-fix-bss-leaks-when-abandoning-assoc-attempts.patch clk-bcm2835-avoid-overwriting-the-div-info-when-disabling-a-pll_div-clk.patch gpio-chardev-return-error-for-seek-operations.patch gpio-stmpe-fix-interrupt-handling-bug.patch mmc-sd-meet-alignment-requirements-for-raw_ssr-dma.patch mmc-sdhci-fix-recovery-from-tuning-timeout.patch perf-annotate-don-t-throw-error-for-zero-length-symbols.patch perf-x86-fix-exclusion-of-bts-and-lbr-for-goldmont.patch perf-x86-intel-cstate-prevent-hotplug-callback-leak.patch regulator-stw481x-vmmc-fix-ages-old-enable-error.patch revert-mmc-sdhci-reset-cmd-and-data-circuits-after-tuning-failure.patch rtl8xxxu-work-around-issue-with-8192eu-and-8723bu-devices-not-reconnecting.patch rtlwifi-fix-enter-exit-power_save.patch ssb-fix-error-routine-when-fallback-sprom-fails.patch thermal-hwmon-properly-report-critical-temperature-in-sysfs.patch timekeeping_force_unsigned_clocksource_to_nanoseconds_conversion.patch --- ...-add-vdd_gpu-regulator-to-jetson-tx1.patch | 58 +++++ ...kup-during-firmware-crash-hw-restart.patch | 60 +++++ ...ot-return-early-to-fix-rcu-unlocking.patch | 78 +++++++ ...gpio_get-to-return-0-or-1-on-success.patch | 39 ++++ ...-for-some-mini-pci-ar9220-mb92-cards.patch | 71 ++++++ ...leaks-when-abandoning-assoc-attempts.patch | 214 ++++++++++++++++++ ...iv-info-when-disabling-a-pll_div-clk.patch | 38 ++++ ...dev-return-error-for-seek-operations.patch | 61 +++++ ...pio-stmpe-fix-interrupt-handling-bug.patch | 50 ++++ ...ignment-requirements-for-raw_ssr-dma.patch | 77 +++++++ ...hci-fix-recovery-from-tuning-timeout.patch | 63 ++++++ ...-throw-error-for-zero-length-symbols.patch | 45 ++++ ...xclusion-of-bts-and-lbr-for-goldmont.patch | 66 ++++++ ...cstate-prevent-hotplug-callback-leak.patch | 75 ++++++ ...w481x-vmmc-fix-ages-old-enable-error.patch | 35 +++ ...d-data-circuits-after-tuning-failure.patch | 36 +++ ...-and-8723bu-devices-not-reconnecting.patch | 45 ++++ .../rtlwifi-fix-enter-exit-power_save.patch | 185 +++++++++++++++ ...or-routine-when-fallback-sprom-fails.patch | 31 +++ ...report-critical-temperature-in-sysfs.patch | 45 ++++ ...locksource_to_nanoseconds_conversion.patch | 138 +++++++++++ 21 files changed, 1510 insertions(+) create mode 100644 queue-4.9/arm64-tegra-add-vdd_gpu-regulator-to-jetson-tx1.patch create mode 100644 queue-4.9/ath10k-fix-soft-lockup-during-firmware-crash-hw-restart.patch create mode 100644 queue-4.9/ath9k-do-not-return-early-to-fix-rcu-unlocking.patch create mode 100644 queue-4.9/ath9k-fix-ath9k_hw_gpio_get-to-return-0-or-1-on-success.patch create mode 100644 queue-4.9/ath9k-really-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch create mode 100644 queue-4.9/cfg80211-mac80211-fix-bss-leaks-when-abandoning-assoc-attempts.patch create mode 100644 queue-4.9/clk-bcm2835-avoid-overwriting-the-div-info-when-disabling-a-pll_div-clk.patch create mode 100644 queue-4.9/gpio-chardev-return-error-for-seek-operations.patch create mode 100644 queue-4.9/gpio-stmpe-fix-interrupt-handling-bug.patch create mode 100644 queue-4.9/mmc-sd-meet-alignment-requirements-for-raw_ssr-dma.patch create mode 100644 queue-4.9/mmc-sdhci-fix-recovery-from-tuning-timeout.patch create mode 100644 queue-4.9/perf-annotate-don-t-throw-error-for-zero-length-symbols.patch create mode 100644 queue-4.9/perf-x86-fix-exclusion-of-bts-and-lbr-for-goldmont.patch create mode 100644 queue-4.9/perf-x86-intel-cstate-prevent-hotplug-callback-leak.patch create mode 100644 queue-4.9/regulator-stw481x-vmmc-fix-ages-old-enable-error.patch create mode 100644 queue-4.9/revert-mmc-sdhci-reset-cmd-and-data-circuits-after-tuning-failure.patch create mode 100644 queue-4.9/rtl8xxxu-work-around-issue-with-8192eu-and-8723bu-devices-not-reconnecting.patch create mode 100644 queue-4.9/rtlwifi-fix-enter-exit-power_save.patch create mode 100644 queue-4.9/ssb-fix-error-routine-when-fallback-sprom-fails.patch create mode 100644 queue-4.9/thermal-hwmon-properly-report-critical-temperature-in-sysfs.patch create mode 100644 queue-4.9/timekeeping_force_unsigned_clocksource_to_nanoseconds_conversion.patch diff --git a/queue-4.9/arm64-tegra-add-vdd_gpu-regulator-to-jetson-tx1.patch b/queue-4.9/arm64-tegra-add-vdd_gpu-regulator-to-jetson-tx1.patch new file mode 100644 index 00000000000..4cd93fab257 --- /dev/null +++ b/queue-4.9/arm64-tegra-add-vdd_gpu-regulator-to-jetson-tx1.patch @@ -0,0 +1,58 @@ +From 5e6b9a89afceadb1ee45472098f7d20af260335c Mon Sep 17 00:00:00 2001 +From: Alexandre Courbot +Date: Fri, 2 Dec 2016 20:57:55 +0100 +Subject: arm64: tegra: Add VDD_GPU regulator to Jetson TX1 + +From: Alexandre Courbot + +commit 5e6b9a89afceadb1ee45472098f7d20af260335c upstream. + +Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson +TX1 board. This addition allows the GPU to be used provided the +bootloader properly enabled the GPU node. + +Signed-off-by: Alexandre Courbot +Signed-off-by: Thierry Reding +[as pointed out by Thierry on IRC, nobody has reported a bug + in the field, but using a new bootloader with a .dtb that + has the incorrect data, it will crash on boot] +Fixes: 336f79c7b6d7 ("arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support") +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi ++++ b/arch/arm64/boot/dts/nvidia/tegra210-p2180.dtsi +@@ -21,6 +21,10 @@ + reg = <0x0 0x80000000 0x1 0x0>; + }; + ++ gpu@57000000 { ++ vdd-supply = <&vdd_gpu>; ++ }; ++ + /* debug port */ + serial@70006000 { + status = "okay"; +@@ -291,4 +295,18 @@ + clock-frequency = <32768>; + }; + }; ++ ++ regulators { ++ vdd_gpu: regulator@100 { ++ compatible = "pwm-regulator"; ++ reg = <100>; ++ pwms = <&pwm 1 4880>; ++ regulator-name = "VDD_GPU"; ++ regulator-min-microvolt = <710000>; ++ regulator-max-microvolt = <1320000>; ++ enable-gpios = <&pmic 6 GPIO_ACTIVE_HIGH>; ++ regulator-ramp-delay = <80>; ++ regulator-enable-ramp-delay = <1000>; ++ }; ++ }; + }; diff --git a/queue-4.9/ath10k-fix-soft-lockup-during-firmware-crash-hw-restart.patch b/queue-4.9/ath10k-fix-soft-lockup-during-firmware-crash-hw-restart.patch new file mode 100644 index 00000000000..8433c7dad5a --- /dev/null +++ b/queue-4.9/ath10k-fix-soft-lockup-during-firmware-crash-hw-restart.patch @@ -0,0 +1,60 @@ +From c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 Mon Sep 17 00:00:00 2001 +From: Mohammed Shafi Shajakhan +Date: Wed, 30 Nov 2016 10:59:29 +0530 +Subject: ath10k: fix soft lockup during firmware crash/hw-restart + +From: Mohammed Shafi Shajakhan + +commit c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 upstream. + +During firmware crash (or) user requested manual restart +the system gets into a soft lock up state because of the +below root cause. + +During user requested hardware restart / firmware crash +the system goes into a soft lockup state as 'napi_synchronize' +is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED' +bit) and it sleeps into infinite loop as it waits for +'NAPI_STATE_SCHED' to be cleared. This condition is hit because +'ath10k_hif_stop' is called twice as below (resulting in calling +'napi_synchronize' after 'napi_disable') + +'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) -> +-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' -> +'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING) + +Fix this by calling 'ath10k_halt' in ath10k_core_restart itself +as it makes more sense before informing mac80211 to restart h/w +Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting' + +Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support") +Signed-off-by: Mohammed Shafi Shajakhan +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath10k/core.c | 2 +- + drivers/net/wireless/ath/ath10k/mac.c | 1 - + 2 files changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/net/wireless/ath/ath10k/core.c ++++ b/drivers/net/wireless/ath/ath10k/core.c +@@ -1534,7 +1534,7 @@ static void ath10k_core_restart(struct w + switch (ar->state) { + case ATH10K_STATE_ON: + ar->state = ATH10K_STATE_RESTARTING; +- ath10k_hif_stop(ar); ++ ath10k_halt(ar); + ath10k_scan_finish(ar); + ieee80211_restart_hw(ar->hw); + break; +--- a/drivers/net/wireless/ath/ath10k/mac.c ++++ b/drivers/net/wireless/ath/ath10k/mac.c +@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211 + ar->state = ATH10K_STATE_ON; + break; + case ATH10K_STATE_RESTARTING: +- ath10k_halt(ar); + ar->state = ATH10K_STATE_RESTARTED; + break; + case ATH10K_STATE_ON: diff --git a/queue-4.9/ath9k-do-not-return-early-to-fix-rcu-unlocking.patch b/queue-4.9/ath9k-do-not-return-early-to-fix-rcu-unlocking.patch new file mode 100644 index 00000000000..8345c311b29 --- /dev/null +++ b/queue-4.9/ath9k-do-not-return-early-to-fix-rcu-unlocking.patch @@ -0,0 +1,78 @@ +From d1f1c0e289e1bc46cd6873ba6dd6c627f459e7fa Mon Sep 17 00:00:00 2001 +From: Tobias Klausmann +Date: Tue, 13 Dec 2016 18:08:07 +0100 +Subject: ath9k: do not return early to fix rcu unlocking + +From: Tobias Klausmann + +commit d1f1c0e289e1bc46cd6873ba6dd6c627f459e7fa upstream. + +Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb +where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on +returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls +and suspicious RCU usage: + + =============================== + [ INFO: suspicious RCU usage. ] + 4.9.0-rc8 #11 Not tainted + ------------------------------- + kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.! + + other info that might help us debug this: + + RCU used illegally from idle CPU! + rcu_scheduler_active = 1, debug_locks = 0 + RCU used illegally from extended quiescent state! + 1 lock held by swapper/7/0: + #0: + ( + rcu_read_lock + ){......} + , at: + [] ath_tx_edma_tasklet+0x0/0x450 [ath9k] + + stack backtrace: + CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11 + Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013 + ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001 + ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8 + ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4 + Call Trace: + + [] dump_stack+0x68/0x93 + [] lockdep_rcu_suspicious+0xd7/0x110 + [] rcu_eqs_enter_common.constprop.85+0x154/0x200 + [] rcu_irq_exit+0x44/0xa0 + [] irq_exit+0x61/0xd0 + [] do_IRQ+0x65/0x110 + [] common_interrupt+0x89/0x89 + + [] ? cpuidle_enter_state+0x151/0x200 + [] cpuidle_enter+0x12/0x20 + [] call_cpuidle+0x1e/0x40 + [] cpu_startup_entry+0x146/0x220 + [] start_secondary+0x148/0x170 + +Signed-off-by: Tobias Klausmann +Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") +Acked-by: Felix Fietkau +Acked-by: Paul E. McKenney +Tested-by: Gabriel Craciunescu +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/xmit.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath/ath9k/xmit.c ++++ b/drivers/net/wireless/ath/ath9k/xmit.c +@@ -2787,7 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_soft + fifo_list = &txq->txq_fifo[txq->txq_tailidx]; + if (list_empty(fifo_list)) { + ath_txq_unlock(sc, txq); +- return; ++ break; + } + + bf = list_first_entry(fifo_list, struct ath_buf, list); diff --git a/queue-4.9/ath9k-fix-ath9k_hw_gpio_get-to-return-0-or-1-on-success.patch b/queue-4.9/ath9k-fix-ath9k_hw_gpio_get-to-return-0-or-1-on-success.patch new file mode 100644 index 00000000000..570eadad9ed --- /dev/null +++ b/queue-4.9/ath9k-fix-ath9k_hw_gpio_get-to-return-0-or-1-on-success.patch @@ -0,0 +1,39 @@ +From 91851cc7a939039bd401adb6ca3da4402bec1d0c Mon Sep 17 00:00:00 2001 +From: Matthias Schiffer +Date: Tue, 15 Nov 2016 18:47:21 +0100 +Subject: ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success + +From: Matthias Schiffer + +commit 91851cc7a939039bd401adb6ca3da4402bec1d0c upstream. + +Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and +SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs, +changing the return on success from 1 to BIT(gpio). This broke some callers +like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the +moment, but should be fixed anyway. + +Instead of fixing all callers, change ath9k_hw_gpio_get() back to only +return 0 or 1. + +Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC") +Signed-off-by: Matthias Schiffer +[kvalo@qca.qualcomm.com: mention that doesn't fix any known bug] +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/hw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath/ath9k/hw.c ++++ b/drivers/net/wireless/ath/ath9k/hw.c +@@ -2792,7 +2792,7 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, + WARN_ON(1); + } + +- return val; ++ return !!val; + } + EXPORT_SYMBOL(ath9k_hw_gpio_get); + diff --git a/queue-4.9/ath9k-really-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch b/queue-4.9/ath9k-really-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch new file mode 100644 index 00000000000..0f9ef81c2a9 --- /dev/null +++ b/queue-4.9/ath9k-really-fix-led-polarity-for-some-mini-pci-ar9220-mb92-cards.patch @@ -0,0 +1,71 @@ +From 79e57dd113d307a6c74773b8aaecf5442068988a Mon Sep 17 00:00:00 2001 +From: "Vittorio Gambaletta (VittGam)" +Date: Wed, 9 Nov 2016 03:40:56 +0200 +Subject: ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards. + +From: Vittorio Gambaletta (VittGam) + +commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream. + +The active_high LED of my Wistron DNMA-92 is still being recognized as +active_low on 4.7.6 mainline. When I was preparing my former commit +0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 +cards.") to fix that I must have somehow messed up with testing, because +I tested the final version of that patch before sending it, and it was +apparently working; but now it is not working on 4.7.6 mainline. + +I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the +PCI_VDEVICE section for 0x0029; but then I moved the former below the +latter after seeing how 0x002A sections were sorted in the file. + +This turned out to be wrong: if a generic PCI_VDEVICE entry (that has +both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more +specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will +match first and will be used. + +With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6. + +While I'm at it, let's fix 0x002A too by also moving its generic definition +below its specific ones. + +Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.") +Signed-off-by: Vittorio Gambaletta +[kvalo@qca.qualcomm.com: improve the commit log based on email discussions] +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/ath/ath9k/pci.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/ath/ath9k/pci.c ++++ b/drivers/net/wireless/ath/ath9k/pci.c +@@ -26,7 +26,6 @@ static const struct pci_device_id ath_pc + { PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */ + { PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */ + { PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */ +- { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */ + + #ifdef CONFIG_ATH9K_PCOEM + /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */ +@@ -37,7 +36,7 @@ static const struct pci_device_id ath_pc + .driver_data = ATH9K_PCI_LED_ACT_HI }, + #endif + +- { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */ ++ { PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */ + + #ifdef CONFIG_ATH9K_PCOEM + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS, +@@ -85,7 +84,11 @@ static const struct pci_device_id ath_pc + 0x10CF, /* Fujitsu */ + 0x1536), + .driver_data = ATH9K_PCI_D3_L1_WAR }, ++#endif + ++ { PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */ ++ ++#ifdef CONFIG_ATH9K_PCOEM + /* AR9285 card for Asus */ + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS, + 0x002B, diff --git a/queue-4.9/cfg80211-mac80211-fix-bss-leaks-when-abandoning-assoc-attempts.patch b/queue-4.9/cfg80211-mac80211-fix-bss-leaks-when-abandoning-assoc-attempts.patch new file mode 100644 index 00000000000..c3b58bb7a6e --- /dev/null +++ b/queue-4.9/cfg80211-mac80211-fix-bss-leaks-when-abandoning-assoc-attempts.patch @@ -0,0 +1,214 @@ +From e6f462df9acd2a3295e5d34eb29e2823220cf129 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Thu, 8 Dec 2016 17:22:09 +0100 +Subject: cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts + +From: Johannes Berg + +commit e6f462df9acd2a3295e5d34eb29e2823220cf129 upstream. + +When mac80211 abandons an association attempt, it may free +all the data structures, but inform cfg80211 and userspace +about it only by sending the deauth frame it received, in +which case cfg80211 has no link to the BSS struct that was +used and will not cfg80211_unhold_bss() it. + +Fix this by providing a way to inform cfg80211 of this with +the BSS entry passed, so that it can clean up properly, and +use this ability in the appropriate places in mac80211. + +This isn't ideal: some code is more or less duplicated and +tracing is missing. However, it's a fairly small change and +it's thus easier to backport - cleanups can come later. + +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + include/net/cfg80211.h | 11 +++++++++++ + net/mac80211/mlme.c | 21 ++++++++++++--------- + net/wireless/core.h | 1 + + net/wireless/mlme.c | 12 ++++++++++++ + net/wireless/sme.c | 14 ++++++++++++++ + 5 files changed, 50 insertions(+), 9 deletions(-) + +--- a/include/net/cfg80211.h ++++ b/include/net/cfg80211.h +@@ -4584,6 +4584,17 @@ void cfg80211_rx_assoc_resp(struct net_d + void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss); + + /** ++ * cfg80211_abandon_assoc - notify cfg80211 of abandoned association attempt ++ * @dev: network device ++ * @bss: The BSS entry with which association was abandoned. ++ * ++ * Call this whenever - for reasons reported through other API, like deauth RX, ++ * an association attempt was abandoned. ++ * This function may sleep. The caller must hold the corresponding wdev's mutex. ++ */ ++void cfg80211_abandon_assoc(struct net_device *dev, struct cfg80211_bss *bss); ++ ++/** + * cfg80211_tx_mlme_mgmt - notification of transmitted deauth/disassoc frame + * @dev: network device + * @buf: 802.11 frame (header + body) +--- a/net/mac80211/mlme.c ++++ b/net/mac80211/mlme.c +@@ -2510,7 +2510,7 @@ static void ieee80211_destroy_auth_data( + } + + static void ieee80211_destroy_assoc_data(struct ieee80211_sub_if_data *sdata, +- bool assoc) ++ bool assoc, bool abandon) + { + struct ieee80211_mgd_assoc_data *assoc_data = sdata->u.mgd.assoc_data; + +@@ -2533,6 +2533,9 @@ static void ieee80211_destroy_assoc_data + mutex_lock(&sdata->local->mtx); + ieee80211_vif_release_channel(sdata); + mutex_unlock(&sdata->local->mtx); ++ ++ if (abandon) ++ cfg80211_abandon_assoc(sdata->dev, assoc_data->bss); + } + + kfree(assoc_data); +@@ -2762,7 +2765,7 @@ static void ieee80211_rx_mgmt_deauth(str + bssid, reason_code, + ieee80211_get_reason_code_string(reason_code)); + +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, true); + + cfg80211_rx_mlme_mgmt(sdata->dev, (u8 *)mgmt, len); + return; +@@ -3167,14 +3170,14 @@ static void ieee80211_rx_mgmt_assoc_resp + if (status_code != WLAN_STATUS_SUCCESS) { + sdata_info(sdata, "%pM denied association (code=%d)\n", + mgmt->sa, status_code); +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, false); + event.u.mlme.status = MLME_DENIED; + event.u.mlme.reason = status_code; + drv_event_callback(sdata->local, sdata, &event); + } else { + if (!ieee80211_assoc_success(sdata, bss, mgmt, len)) { + /* oops -- internal error -- send timeout for now */ +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, false); + cfg80211_assoc_timeout(sdata->dev, bss); + return; + } +@@ -3187,7 +3190,7 @@ static void ieee80211_rx_mgmt_assoc_resp + * recalc after assoc_data is NULL but before associated + * is set can cause the interface to go idle + */ +- ieee80211_destroy_assoc_data(sdata, true); ++ ieee80211_destroy_assoc_data(sdata, true, false); + + /* get uapsd queues configuration */ + uapsd_queues = 0; +@@ -3886,7 +3889,7 @@ void ieee80211_sta_work(struct ieee80211 + .u.mlme.status = MLME_TIMEOUT, + }; + +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, false); + cfg80211_assoc_timeout(sdata->dev, bss); + drv_event_callback(sdata->local, sdata, &event); + } +@@ -4025,7 +4028,7 @@ void ieee80211_mgd_quiesce(struct ieee80 + WLAN_REASON_DEAUTH_LEAVING, + false, frame_buf); + if (ifmgd->assoc_data) +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, true); + if (ifmgd->auth_data) + ieee80211_destroy_auth_data(sdata, false); + cfg80211_tx_mlme_mgmt(sdata->dev, frame_buf, +@@ -4907,7 +4910,7 @@ int ieee80211_mgd_deauth(struct ieee8021 + IEEE80211_STYPE_DEAUTH, + req->reason_code, tx, + frame_buf); +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, true); + ieee80211_report_disconnect(sdata, frame_buf, + sizeof(frame_buf), true, + req->reason_code); +@@ -4982,7 +4985,7 @@ void ieee80211_mgd_stop(struct ieee80211 + sdata_lock(sdata); + if (ifmgd->assoc_data) { + struct cfg80211_bss *bss = ifmgd->assoc_data->bss; +- ieee80211_destroy_assoc_data(sdata, false); ++ ieee80211_destroy_assoc_data(sdata, false, false); + cfg80211_assoc_timeout(sdata->dev, bss); + } + if (ifmgd->auth_data) +--- a/net/wireless/core.h ++++ b/net/wireless/core.h +@@ -410,6 +410,7 @@ void cfg80211_sme_disassoc(struct wirele + void cfg80211_sme_deauth(struct wireless_dev *wdev); + void cfg80211_sme_auth_timeout(struct wireless_dev *wdev); + void cfg80211_sme_assoc_timeout(struct wireless_dev *wdev); ++void cfg80211_sme_abandon_assoc(struct wireless_dev *wdev); + + /* internal helpers */ + bool cfg80211_supported_cipher_suite(struct wiphy *wiphy, u32 cipher); +--- a/net/wireless/mlme.c ++++ b/net/wireless/mlme.c +@@ -149,6 +149,18 @@ void cfg80211_assoc_timeout(struct net_d + } + EXPORT_SYMBOL(cfg80211_assoc_timeout); + ++void cfg80211_abandon_assoc(struct net_device *dev, struct cfg80211_bss *bss) ++{ ++ struct wireless_dev *wdev = dev->ieee80211_ptr; ++ struct wiphy *wiphy = wdev->wiphy; ++ ++ cfg80211_sme_abandon_assoc(wdev); ++ ++ cfg80211_unhold_bss(bss_from_pub(bss)); ++ cfg80211_put_bss(wiphy, bss); ++} ++EXPORT_SYMBOL(cfg80211_abandon_assoc); ++ + void cfg80211_tx_mlme_mgmt(struct net_device *dev, const u8 *buf, size_t len) + { + struct wireless_dev *wdev = dev->ieee80211_ptr; +--- a/net/wireless/sme.c ++++ b/net/wireless/sme.c +@@ -39,6 +39,7 @@ struct cfg80211_conn { + CFG80211_CONN_ASSOCIATING, + CFG80211_CONN_ASSOC_FAILED, + CFG80211_CONN_DEAUTH, ++ CFG80211_CONN_ABANDON, + CFG80211_CONN_CONNECTED, + } state; + u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN]; +@@ -206,6 +207,8 @@ static int cfg80211_conn_do_work(struct + cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid, + NULL, 0, + WLAN_REASON_DEAUTH_LEAVING, false); ++ /* fall through */ ++ case CFG80211_CONN_ABANDON: + /* free directly, disconnected event already sent */ + cfg80211_sme_free(wdev); + return 0; +@@ -423,6 +426,17 @@ void cfg80211_sme_assoc_timeout(struct w + schedule_work(&rdev->conn_work); + } + ++void cfg80211_sme_abandon_assoc(struct wireless_dev *wdev) ++{ ++ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy); ++ ++ if (!wdev->conn) ++ return; ++ ++ wdev->conn->state = CFG80211_CONN_ABANDON; ++ schedule_work(&rdev->conn_work); ++} ++ + static int cfg80211_sme_get_conn_ies(struct wireless_dev *wdev, + const u8 *ies, size_t ies_len, + const u8 **out_ies, size_t *out_ies_len) diff --git a/queue-4.9/clk-bcm2835-avoid-overwriting-the-div-info-when-disabling-a-pll_div-clk.patch b/queue-4.9/clk-bcm2835-avoid-overwriting-the-div-info-when-disabling-a-pll_div-clk.patch new file mode 100644 index 00000000000..91a55212342 --- /dev/null +++ b/queue-4.9/clk-bcm2835-avoid-overwriting-the-div-info-when-disabling-a-pll_div-clk.patch @@ -0,0 +1,38 @@ +From 68af4fa8f39b542a6cde7ac19518d88e9b3099dc Mon Sep 17 00:00:00 2001 +From: Boris Brezillon +Date: Thu, 1 Dec 2016 20:27:21 +0100 +Subject: clk: bcm2835: Avoid overwriting the div info when disabling a pll_div clk + +From: Boris Brezillon + +commit 68af4fa8f39b542a6cde7ac19518d88e9b3099dc upstream. + +bcm2835_pll_divider_off() is resetting the divider field in the A2W reg +to zero when disabling the clock. + +Make sure we preserve this value by reading the previous a2w_reg value +first and ORing the result with A2W_PLL_CHANNEL_DISABLE. + +Signed-off-by: Boris Brezillon +Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") +Reviewed-by: Eric Anholt +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clk/bcm/clk-bcm2835.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/clk/bcm/clk-bcm2835.c ++++ b/drivers/clk/bcm/clk-bcm2835.c +@@ -751,7 +751,9 @@ static void bcm2835_pll_divider_off(stru + cprman_write(cprman, data->cm_reg, + (cprman_read(cprman, data->cm_reg) & + ~data->load_mask) | data->hold_mask); +- cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE); ++ cprman_write(cprman, data->a2w_reg, ++ cprman_read(cprman, data->a2w_reg) | ++ A2W_PLL_CHANNEL_DISABLE); + spin_unlock(&cprman->regs_lock); + } + diff --git a/queue-4.9/gpio-chardev-return-error-for-seek-operations.patch b/queue-4.9/gpio-chardev-return-error-for-seek-operations.patch new file mode 100644 index 00000000000..e8459babe62 --- /dev/null +++ b/queue-4.9/gpio-chardev-return-error-for-seek-operations.patch @@ -0,0 +1,61 @@ +From f4e81c529767b9a33d1b27695c54dc84a14af30d Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Wed, 30 Nov 2016 13:05:21 +0100 +Subject: gpio: chardev: Return error for seek operations + +From: Lars-Peter Clausen + +commit f4e81c529767b9a33d1b27695c54dc84a14af30d upstream. + +The GPIO chardev is used for management tasks (allocating line and event +handles) and does neither support read() nor write() operations. Hence it +does not make much sense to allow seek operations. + +Currently the chardev uses noop_llseek() for its seek implementation. This +function does not move the pointer and simply returns the current position +(always 0 for the GPIO chardev). noop_llseek() is primarily meant for +devices that can not support seek, but where there might be a user that +depends on the seek() operation succeeding. For newly added devices that +can not support seek operations it is recommended to use no_llseek(), which +will return an error. For more information see commit 6038f373a3dc +("llseek: automatically add .llseek fop"). + +Unfortunately this was overlooked when the GPIO chardev ABI was introduced. +But it is highly unlikely that since then userspace applications have +appeared that rely on being able to perform non-failing seek operations on +a GPIO chardev file descriptor. So it should be safe to change from +noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev +open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags +from the file. Neither of these should be set on a file that does not +support seek operations. + +Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -986,7 +986,8 @@ static int gpio_chrdev_open(struct inode + return -ENODEV; + get_device(&gdev->dev); + filp->private_data = gdev; +- return 0; ++ ++ return nonseekable_open(inode, filp); + } + + /** +@@ -1011,7 +1012,7 @@ static const struct file_operations gpio + .release = gpio_chrdev_release, + .open = gpio_chrdev_open, + .owner = THIS_MODULE, +- .llseek = noop_llseek, ++ .llseek = no_llseek, + .unlocked_ioctl = gpio_ioctl, + #ifdef CONFIG_COMPAT + .compat_ioctl = gpio_ioctl_compat, diff --git a/queue-4.9/gpio-stmpe-fix-interrupt-handling-bug.patch b/queue-4.9/gpio-stmpe-fix-interrupt-handling-bug.patch new file mode 100644 index 00000000000..c5124420f18 --- /dev/null +++ b/queue-4.9/gpio-stmpe-fix-interrupt-handling-bug.patch @@ -0,0 +1,50 @@ +From 1516c6350aa2770b8a5e36d40c3ec5078f92ba70 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Wed, 23 Nov 2016 23:21:17 +0100 +Subject: gpio: stmpe: fix interrupt handling bug + +From: Linus Walleij + +commit 1516c6350aa2770b8a5e36d40c3ec5078f92ba70 upstream. + +commit 43db289d00c6 ("gpio: stmpe: Rework registers access") +reworked the STMPE register access so as to use +[STMPE_IDX_*_LSB + i] to access the 8bit register for a +certain bank, assuming the CSB and MSB will follow after +the enumerator. For this to work the index needs to go from +(size-1) to 0 not 0 to (size-1). + +However for the GPIO IRQ handler, the status registers we read +register MSB + 3 bytes ahead for the 24 bit GPIOs and index +registers from MSB upwards and run an index i over the +registers UNLESS we are STMPE1600. + +This is not working when we get to clearing the interrupt +EDGE status register STMPE_IDX_GPEDR_[LCM]SB: it is indexed +like all other registers [STMPE_IDX_*_LSB + i] but in this +loop we index from 0 to get the right bank index for the +calculations, and we need to just add i to the MSB. + +Before this, interrupts on the STMPE2401 were broken, this +patch fixes it so it works again. + +Cc: Patrice Chotard +Fixes: 43db289d00c6 ("gpio: stmpe: Rework registers access") +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpio-stmpe.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpio/gpio-stmpe.c ++++ b/drivers/gpio/gpio-stmpe.c +@@ -413,7 +413,7 @@ static irqreturn_t stmpe_gpio_irq(int ir + stmpe->partnum != STMPE1801) { + stmpe_reg_write(stmpe, statmsbreg + i, status[i]); + stmpe_reg_write(stmpe, +- stmpe->regs[STMPE_IDX_GPEDR_LSB + i], ++ stmpe->regs[STMPE_IDX_GPEDR_MSB] + i, + status[i]); + } + } diff --git a/queue-4.9/mmc-sd-meet-alignment-requirements-for-raw_ssr-dma.patch b/queue-4.9/mmc-sd-meet-alignment-requirements-for-raw_ssr-dma.patch new file mode 100644 index 00000000000..4bba3d87e07 --- /dev/null +++ b/queue-4.9/mmc-sd-meet-alignment-requirements-for-raw_ssr-dma.patch @@ -0,0 +1,77 @@ +From e85baa8868b016513c0f5738362402495b1a66a5 Mon Sep 17 00:00:00 2001 +From: Paul Burton +Date: Fri, 11 Nov 2016 14:22:36 +0000 +Subject: mmc: sd: Meet alignment requirements for raw_ssr DMA +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Paul Burton + +commit e85baa8868b016513c0f5738362402495b1a66a5 upstream. + +The mmc_read_ssr() function results in DMA to the raw_ssr member of +struct mmc_card, which is not guaranteed to be cache line aligned & thus +might not meet the requirements set out in Documentation/DMA-API.txt: + + Warnings: Memory coherency operates at a granularity called the cache + line width. In order for memory mapped by this API to operate + correctly, the mapped region must begin exactly on a cache line + boundary and end exactly on one (to prevent two separately mapped + regions from sharing a single cache line). Since the cache line size + may not be known at compile time, the API will not enforce this + requirement. Therefore, it is recommended that driver writers who + don't take special care to determine the cache line size at run time + only map virtual regions that begin and end on page boundaries (which + are guaranteed also to be cache line boundaries). + +On some systems where DMA is non-coherent this can lead to us losing +data that shares cache lines with the raw_ssr array. + +Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc +will ensure the buffer is suitably aligned, allowing the DMA to be +performed without any loss of data. + +Signed-off-by: Paul Burton +Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute") +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/sd.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/core/sd.c ++++ b/drivers/mmc/core/sd.c +@@ -223,6 +223,7 @@ static int mmc_decode_scr(struct mmc_car + static int mmc_read_ssr(struct mmc_card *card) + { + unsigned int au, es, et, eo; ++ u32 *raw_ssr; + int i; + + if (!(card->csd.cmdclass & CCC_APP_SPEC)) { +@@ -231,14 +232,21 @@ static int mmc_read_ssr(struct mmc_card + return 0; + } + +- if (mmc_app_sd_status(card, card->raw_ssr)) { ++ raw_ssr = kmalloc(sizeof(card->raw_ssr), GFP_KERNEL); ++ if (!raw_ssr) ++ return -ENOMEM; ++ ++ if (mmc_app_sd_status(card, raw_ssr)) { + pr_warn("%s: problem reading SD Status register\n", + mmc_hostname(card->host)); ++ kfree(raw_ssr); + return 0; + } + + for (i = 0; i < 16; i++) +- card->raw_ssr[i] = be32_to_cpu(card->raw_ssr[i]); ++ card->raw_ssr[i] = be32_to_cpu(raw_ssr[i]); ++ ++ kfree(raw_ssr); + + /* + * UNSTUFF_BITS only works with four u32s so we have to offset the diff --git a/queue-4.9/mmc-sdhci-fix-recovery-from-tuning-timeout.patch b/queue-4.9/mmc-sdhci-fix-recovery-from-tuning-timeout.patch new file mode 100644 index 00000000000..514517a80db --- /dev/null +++ b/queue-4.9/mmc-sdhci-fix-recovery-from-tuning-timeout.patch @@ -0,0 +1,63 @@ +From 61e53bd0047d58caee0c7170613045bf96de4458 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 2 Dec 2016 15:14:20 +0200 +Subject: mmc: sdhci: Fix recovery from tuning timeout + +From: Adrian Hunter + +commit 61e53bd0047d58caee0c7170613045bf96de4458 upstream. + +Clearing the tuning bits should reset the tuning circuit. However there is +more to do. Reset the command and data lines for good measure, and then +for eMMC ensure the card is not still trying to process a tuning command by +sending a stop command. + +Note the JEDEC eMMC specification says the stop command (CMD12) can be used +to stop a tuning command (CMD21) whereas the SD specification is silent on +the subject with respect to the SD tuning command (CMD19). Considering that +CMD12 is not a valid SDIO command, the stop command is sent only when the +tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far +which have been on eMMC. + +Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and +data circuits after tuning failure") which is being reverted for v4.9+. + +Signed-off-by: Adrian Hunter +Tested-by: Dan O'Donovan +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/drivers/mmc/host/sdhci.c ++++ b/drivers/mmc/host/sdhci.c +@@ -2091,7 +2091,27 @@ static int sdhci_execute_tuning(struct m + ctrl &= ~SDHCI_CTRL_EXEC_TUNING; + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2); + ++ sdhci_do_reset(host, SDHCI_RESET_CMD); ++ sdhci_do_reset(host, SDHCI_RESET_DATA); ++ + err = -EIO; ++ ++ if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200) ++ goto out; ++ ++ sdhci_writel(host, host->ier, SDHCI_INT_ENABLE); ++ sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE); ++ ++ spin_unlock_irqrestore(&host->lock, flags); ++ ++ memset(&cmd, 0, sizeof(cmd)); ++ cmd.opcode = MMC_STOP_TRANSMISSION; ++ cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC; ++ cmd.busy_timeout = 50; ++ mmc_wait_for_cmd(mmc, &cmd, 0); ++ ++ spin_lock_irqsave(&host->lock, flags); ++ + goto out; + } + diff --git a/queue-4.9/perf-annotate-don-t-throw-error-for-zero-length-symbols.patch b/queue-4.9/perf-annotate-don-t-throw-error-for-zero-length-symbols.patch new file mode 100644 index 00000000000..30fd696f0cc --- /dev/null +++ b/queue-4.9/perf-annotate-don-t-throw-error-for-zero-length-symbols.patch @@ -0,0 +1,45 @@ +From edee44be59190bf22d5c6e521f3852b7ff16862f Mon Sep 17 00:00:00 2001 +From: Ravi Bangoria +Date: Tue, 22 Nov 2016 14:10:50 +0530 +Subject: perf annotate: Don't throw error for zero length symbols + +From: Ravi Bangoria + +commit edee44be59190bf22d5c6e521f3852b7ff16862f upstream. + +'perf report --tui' exits with error when it finds a sample of zero +length symbol (i.e. addr == sym->start == sym->end). Actually these are +valid samples. Don't exit TUI and show report with such symbols. + +Reported-and-Tested-by: Anton Blanchard +Link: https://lkml.org/lkml/2016/10/8/189 +Signed-off-by: Ravi Bangoria +Cc: Alexander Shishkin +Cc: Benjamin Herrenschmidt +Cc: Chris Riyder +Cc: linuxppc-dev@lists.ozlabs.org +Cc: Masami Hiramatsu +Cc: Michael Ellerman +Cc: Nicholas Piggin +Cc: Paul Mackerras +Cc: Peter Zijlstra +Link: http://lkml.kernel.org/r/1479804050-5028-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/annotate.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/tools/perf/util/annotate.c ++++ b/tools/perf/util/annotate.c +@@ -593,7 +593,8 @@ static int __symbol__inc_addr_samples(st + + pr_debug3("%s: addr=%#" PRIx64 "\n", __func__, map->unmap_ip(map, addr)); + +- if (addr < sym->start || addr >= sym->end) { ++ if ((addr < sym->start || addr >= sym->end) && ++ (addr != sym->end || sym->start != sym->end)) { + pr_debug("%s(%d): ERANGE! sym->name=%s, start=%#" PRIx64 ", addr=%#" PRIx64 ", end=%#" PRIx64 "\n", + __func__, __LINE__, sym->name, sym->start, addr, sym->end); + return -ERANGE; diff --git a/queue-4.9/perf-x86-fix-exclusion-of-bts-and-lbr-for-goldmont.patch b/queue-4.9/perf-x86-fix-exclusion-of-bts-and-lbr-for-goldmont.patch new file mode 100644 index 00000000000..5bf8051cdd0 --- /dev/null +++ b/queue-4.9/perf-x86-fix-exclusion-of-bts-and-lbr-for-goldmont.patch @@ -0,0 +1,66 @@ +From b0c1ef52959582144bbea9a2b37db7f4c9e399f7 Mon Sep 17 00:00:00 2001 +From: Andi Kleen +Date: Thu, 8 Dec 2016 16:14:17 -0800 +Subject: perf/x86: Fix exclusion of BTS and LBR for Goldmont + +From: Andi Kleen + +commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream. + +An earlier patch allowed enabling PT and LBR at the same +time on Goldmont. However it also allowed enabling BTS and LBR +at the same time, which is still not supported. Fix this by +bypassing the check only for PT. + +Signed-off-by: Andi Kleen +Signed-off-by: Peter Zijlstra (Intel) +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: alexander.shishkin@intel.com +Cc: kan.liang@intel.com +Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") +Link: http://lkml.kernel.org/r/20161209001417.4713-1-andi@firstfloor.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/core.c | 8 ++++++-- + arch/x86/events/perf_event.h | 2 +- + 2 files changed, 7 insertions(+), 3 deletions(-) + +--- a/arch/x86/events/core.c ++++ b/arch/x86/events/core.c +@@ -365,7 +365,11 @@ int x86_add_exclusive(unsigned int what) + { + int i; + +- if (x86_pmu.lbr_pt_coexist) ++ /* ++ * When lbr_pt_coexist we allow PT to coexist with either LBR or BTS. ++ * LBR and BTS are still mutually exclusive. ++ */ ++ if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt) + return 0; + + if (!atomic_inc_not_zero(&x86_pmu.lbr_exclusive[what])) { +@@ -388,7 +392,7 @@ fail_unlock: + + void x86_del_exclusive(unsigned int what) + { +- if (x86_pmu.lbr_pt_coexist) ++ if (x86_pmu.lbr_pt_coexist && what == x86_lbr_exclusive_pt) + return; + + atomic_dec(&x86_pmu.lbr_exclusive[what]); +--- a/arch/x86/events/perf_event.h ++++ b/arch/x86/events/perf_event.h +@@ -604,7 +604,7 @@ struct x86_pmu { + u64 lbr_sel_mask; /* LBR_SELECT valid bits */ + const int *lbr_sel_map; /* lbr_select mappings */ + bool lbr_double_abort; /* duplicated lbr aborts */ +- bool lbr_pt_coexist; /* LBR may coexist with PT */ ++ bool lbr_pt_coexist; /* (LBR|BTS) may coexist with PT */ + + /* + * Intel PT/LBR/BTS are exclusive diff --git a/queue-4.9/perf-x86-intel-cstate-prevent-hotplug-callback-leak.patch b/queue-4.9/perf-x86-intel-cstate-prevent-hotplug-callback-leak.patch new file mode 100644 index 00000000000..2c67a2abe2b --- /dev/null +++ b/queue-4.9/perf-x86-intel-cstate-prevent-hotplug-callback-leak.patch @@ -0,0 +1,75 @@ +From 834fcd298003c10ce450e66960c78893cb1cc4b5 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 22 Dec 2016 11:02:08 +0100 +Subject: perf/x86/intel/cstate: Prevent hotplug callback leak + +From: Thomas Gleixner + +commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream. + +If the pmu registration fails the registered hotplug callbacks are not +removed. Wrong in any case, but fatal in case of a modular driver. + +Replace the nonsensical state names with proper ones while at it. + +Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug state machine") +Signed-off-by: Thomas Gleixner +Cc: Sebastian Siewior +Cc: Peter Zijlstra +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/intel/cstate.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/arch/x86/events/intel/cstate.c ++++ b/arch/x86/events/intel/cstate.c +@@ -594,6 +594,9 @@ static int __init cstate_probe(const str + + static inline void cstate_cleanup(void) + { ++ cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE); ++ cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING); ++ + if (has_cstate_core) + perf_pmu_unregister(&cstate_core_pmu); + +@@ -606,16 +609,16 @@ static int __init cstate_init(void) + int err; + + cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_STARTING, +- "AP_PERF_X86_CSTATE_STARTING", cstate_cpu_init, +- NULL); ++ "perf/x86/cstate:starting", cstate_cpu_init, NULL); + cpuhp_setup_state(CPUHP_AP_PERF_X86_CSTATE_ONLINE, +- "AP_PERF_X86_CSTATE_ONLINE", NULL, cstate_cpu_exit); ++ "perf/x86/cstate:online", NULL, cstate_cpu_exit); + + if (has_cstate_core) { + err = perf_pmu_register(&cstate_core_pmu, cstate_core_pmu.name, -1); + if (err) { + has_cstate_core = false; + pr_info("Failed to register cstate core pmu\n"); ++ cstate_cleanup(); + return err; + } + } +@@ -629,8 +632,7 @@ static int __init cstate_init(void) + return err; + } + } +- +- return err; ++ return 0; + } + + static int __init cstate_pmu_init(void) +@@ -655,8 +657,6 @@ module_init(cstate_pmu_init); + + static void __exit cstate_pmu_exit(void) + { +- cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_ONLINE); +- cpuhp_remove_state_nocalls(CPUHP_AP_PERF_X86_CSTATE_STARTING); + cstate_cleanup(); + } + module_exit(cstate_pmu_exit); diff --git a/queue-4.9/regulator-stw481x-vmmc-fix-ages-old-enable-error.patch b/queue-4.9/regulator-stw481x-vmmc-fix-ages-old-enable-error.patch new file mode 100644 index 00000000000..6b15f4eceb1 --- /dev/null +++ b/queue-4.9/regulator-stw481x-vmmc-fix-ages-old-enable-error.patch @@ -0,0 +1,35 @@ +From 295070e9aa015abb9b92cccfbb1e43954e938133 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Sat, 12 Nov 2016 15:22:38 +0100 +Subject: regulator: stw481x-vmmc: fix ages old enable error + +From: Linus Walleij + +commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream. + +The regulator has never been properly enabled, it has been +dormant all the time. It's strange that MMC was working +at all, but it likely worked by the signals going through +the levelshifter and reaching the card anyways. + +Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver") +Signed-off-by: Linus Walleij +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/regulator/stw481x-vmmc.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/regulator/stw481x-vmmc.c ++++ b/drivers/regulator/stw481x-vmmc.c +@@ -47,7 +47,8 @@ static struct regulator_desc vmmc_regula + .volt_table = stw481x_vmmc_voltages, + .enable_time = 200, /* FIXME: look this up */ + .enable_reg = STW_CONF1, +- .enable_mask = STW_CONF1_PDN_VMMC, ++ .enable_mask = STW_CONF1_PDN_VMMC | STW_CONF1_MMC_LS_STATUS, ++ .enable_val = STW_CONF1_PDN_VMMC, + .vsel_reg = STW_CONF1, + .vsel_mask = STW_CONF1_VMMC_MASK, + }; diff --git a/queue-4.9/revert-mmc-sdhci-reset-cmd-and-data-circuits-after-tuning-failure.patch b/queue-4.9/revert-mmc-sdhci-reset-cmd-and-data-circuits-after-tuning-failure.patch new file mode 100644 index 00000000000..08a67586a7d --- /dev/null +++ b/queue-4.9/revert-mmc-sdhci-reset-cmd-and-data-circuits-after-tuning-failure.patch @@ -0,0 +1,36 @@ +From 2ca71c27eeaeddae38efe24a84b20e22708a3d1d Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 2 Dec 2016 15:14:19 +0200 +Subject: Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure" + +From: Adrian Hunter + +commit 2ca71c27eeaeddae38efe24a84b20e22708a3d1d upstream. + +This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits +after tuning failure"). + +A better fix is available, and it will be applied to older stable releases, +so get this out of the way by reverting it. + +Signed-off-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/drivers/mmc/host/sdhci.c ++++ b/drivers/mmc/host/sdhci.c +@@ -2086,10 +2086,6 @@ static int sdhci_execute_tuning(struct m + + if (!host->tuning_done) { + pr_info(DRIVER_NAME ": Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock\n"); +- +- sdhci_do_reset(host, SDHCI_RESET_CMD); +- sdhci_do_reset(host, SDHCI_RESET_DATA); +- + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2); + ctrl &= ~SDHCI_CTRL_TUNED_CLK; + ctrl &= ~SDHCI_CTRL_EXEC_TUNING; diff --git a/queue-4.9/rtl8xxxu-work-around-issue-with-8192eu-and-8723bu-devices-not-reconnecting.patch b/queue-4.9/rtl8xxxu-work-around-issue-with-8192eu-and-8723bu-devices-not-reconnecting.patch new file mode 100644 index 00000000000..0ed8fb2c959 --- /dev/null +++ b/queue-4.9/rtl8xxxu-work-around-issue-with-8192eu-and-8723bu-devices-not-reconnecting.patch @@ -0,0 +1,45 @@ +From c59f13bbead475096bdfebc7ef59c12e180858de Mon Sep 17 00:00:00 2001 +From: Jes Sorensen +Date: Tue, 29 Nov 2016 18:59:02 -0500 +Subject: rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting + +From: Jes Sorensen + +commit c59f13bbead475096bdfebc7ef59c12e180858de upstream. + +The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and +8723bu devices not being able to reconnect. + +Reported-by: Barry Day +Signed-off-by: Jes Sorensen +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c ++++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +@@ -4372,6 +4372,13 @@ void rtl8xxxu_gen1_report_connect(struct + void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv, + u8 macid, bool connect) + { ++#ifdef RTL8XXXU_GEN2_REPORT_CONNECT ++ /* ++ * Barry Day reports this causes issues with 8192eu and 8723bu ++ * devices reconnecting. The reason for this is unclear, but ++ * until it is better understood, leave the code in place but ++ * disabled, so it is not lost. ++ */ + struct h2c_cmd h2c; + + memset(&h2c, 0, sizeof(struct h2c_cmd)); +@@ -4383,6 +4390,7 @@ void rtl8xxxu_gen2_report_connect(struct + h2c.media_status_rpt.parm &= ~BIT(0); + + rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt)); ++#endif + } + + void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv) diff --git a/queue-4.9/rtlwifi-fix-enter-exit-power_save.patch b/queue-4.9/rtlwifi-fix-enter-exit-power_save.patch new file mode 100644 index 00000000000..42d681e57d2 --- /dev/null +++ b/queue-4.9/rtlwifi-fix-enter-exit-power_save.patch @@ -0,0 +1,185 @@ +From ba9f93f82abafe2552eac942ebb11c2df4f8dd7f Mon Sep 17 00:00:00 2001 +From: Larry Finger +Date: Sat, 26 Nov 2016 14:43:35 -0600 +Subject: rtlwifi: Fix enter/exit power_save + +From: Larry Finger + +commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream. + +In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and +commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() +to use work queue"), an error was introduced in the power-save routines +due to the fact that leaving PS was delayed by the use of a work queue. + +This problem is fixed by detecting if the enter or leave routines are +in interrupt mode. If so, the workqueue is used to place the request. +If in normal mode, the enter or leave routines are called directly. + +Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue") +Reported-by: Ping-Ke Shih +Signed-off-by: Larry Finger +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/realtek/rtlwifi/base.c | 8 +++--- + drivers/net/wireless/realtek/rtlwifi/core.c | 9 ++----- + drivers/net/wireless/realtek/rtlwifi/pci.c | 14 +++------- + drivers/net/wireless/realtek/rtlwifi/ps.c | 36 +++++++++++++++++++++------- + 4 files changed, 40 insertions(+), 27 deletions(-) + +--- a/drivers/net/wireless/realtek/rtlwifi/base.c ++++ b/drivers/net/wireless/realtek/rtlwifi/base.c +@@ -1303,12 +1303,13 @@ EXPORT_SYMBOL_GPL(rtl_action_proc); + + static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc) + { ++ struct ieee80211_hw *hw = rtlpriv->hw; ++ + rtlpriv->ra.is_special_data = true; + if (rtlpriv->cfg->ops->get_btc_status()) + rtlpriv->btcoexist.btc_ops->btc_special_packet_notify( + rtlpriv, 1); +- rtlpriv->enter_ps = false; +- schedule_work(&rtlpriv->works.lps_change_work); ++ rtl_lps_leave(hw); + ppsc->last_delaylps_stamp_jiffies = jiffies; + } + +@@ -1381,8 +1382,7 @@ u8 rtl_is_special_data(struct ieee80211_ + + if (is_tx) { + rtlpriv->ra.is_special_data = true; +- rtlpriv->enter_ps = false; +- schedule_work(&rtlpriv->works.lps_change_work); ++ rtl_lps_leave(hw); + ppsc->last_delaylps_stamp_jiffies = jiffies; + } + +--- a/drivers/net/wireless/realtek/rtlwifi/core.c ++++ b/drivers/net/wireless/realtek/rtlwifi/core.c +@@ -1150,10 +1150,8 @@ static void rtl_op_bss_info_changed(stru + } else { + mstatus = RT_MEDIA_DISCONNECT; + +- if (mac->link_state == MAC80211_LINKED) { +- rtlpriv->enter_ps = false; +- schedule_work(&rtlpriv->works.lps_change_work); +- } ++ if (mac->link_state == MAC80211_LINKED) ++ rtl_lps_leave(hw); + if (ppsc->p2p_ps_info.p2p_ps_mode > P2P_PS_NONE) + rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE); + mac->link_state = MAC80211_NOLINK; +@@ -1431,8 +1429,7 @@ static void rtl_op_sw_scan_start(struct + } + + if (mac->link_state == MAC80211_LINKED) { +- rtlpriv->enter_ps = false; +- schedule_work(&rtlpriv->works.lps_change_work); ++ rtl_lps_leave(hw); + mac->link_state = MAC80211_LINKED_SCANNING; + } else { + rtl_ips_nic_on(hw); +--- a/drivers/net/wireless/realtek/rtlwifi/pci.c ++++ b/drivers/net/wireless/realtek/rtlwifi/pci.c +@@ -663,11 +663,9 @@ tx_status_ok: + } + + if (((rtlpriv->link_info.num_rx_inperiod + +- rtlpriv->link_info.num_tx_inperiod) > 8) || +- (rtlpriv->link_info.num_rx_inperiod > 2)) { +- rtlpriv->enter_ps = false; +- schedule_work(&rtlpriv->works.lps_change_work); +- } ++ rtlpriv->link_info.num_tx_inperiod) > 8) || ++ (rtlpriv->link_info.num_rx_inperiod > 2)) ++ rtl_lps_leave(hw); + } + + static int _rtl_pci_init_one_rxdesc(struct ieee80211_hw *hw, +@@ -918,10 +916,8 @@ new_trx_end: + } + if (((rtlpriv->link_info.num_rx_inperiod + + rtlpriv->link_info.num_tx_inperiod) > 8) || +- (rtlpriv->link_info.num_rx_inperiod > 2)) { +- rtlpriv->enter_ps = false; +- schedule_work(&rtlpriv->works.lps_change_work); +- } ++ (rtlpriv->link_info.num_rx_inperiod > 2)) ++ rtl_lps_leave(hw); + skb = new_skb; + no_new: + if (rtlpriv->use_new_trx_flow) { +--- a/drivers/net/wireless/realtek/rtlwifi/ps.c ++++ b/drivers/net/wireless/realtek/rtlwifi/ps.c +@@ -407,8 +407,8 @@ void rtl_lps_set_psmode(struct ieee80211 + } + } + +-/*Enter the leisure power save mode.*/ +-void rtl_lps_enter(struct ieee80211_hw *hw) ++/* Interrupt safe routine to enter the leisure power save mode.*/ ++static void rtl_lps_enter_core(struct ieee80211_hw *hw) + { + struct rtl_mac *mac = rtl_mac(rtl_priv(hw)); + struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw)); +@@ -444,10 +444,9 @@ void rtl_lps_enter(struct ieee80211_hw * + + spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag); + } +-EXPORT_SYMBOL(rtl_lps_enter); + +-/*Leave the leisure power save mode.*/ +-void rtl_lps_leave(struct ieee80211_hw *hw) ++/* Interrupt safe routine to leave the leisure power save mode.*/ ++static void rtl_lps_leave_core(struct ieee80211_hw *hw) + { + struct rtl_priv *rtlpriv = rtl_priv(hw); + struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw)); +@@ -477,7 +476,6 @@ void rtl_lps_leave(struct ieee80211_hw * + } + spin_unlock_irqrestore(&rtlpriv->locks.lps_lock, flag); + } +-EXPORT_SYMBOL(rtl_lps_leave); + + /* For sw LPS*/ + void rtl_swlps_beacon(struct ieee80211_hw *hw, void *data, unsigned int len) +@@ -670,12 +668,34 @@ void rtl_lps_change_work_callback(struct + struct rtl_priv *rtlpriv = rtl_priv(hw); + + if (rtlpriv->enter_ps) +- rtl_lps_enter(hw); ++ rtl_lps_enter_core(hw); + else +- rtl_lps_leave(hw); ++ rtl_lps_leave_core(hw); + } + EXPORT_SYMBOL_GPL(rtl_lps_change_work_callback); + ++void rtl_lps_enter(struct ieee80211_hw *hw) ++{ ++ struct rtl_priv *rtlpriv = rtl_priv(hw); ++ ++ if (!in_interrupt()) ++ return rtl_lps_enter_core(hw); ++ rtlpriv->enter_ps = true; ++ schedule_work(&rtlpriv->works.lps_change_work); ++} ++EXPORT_SYMBOL_GPL(rtl_lps_enter); ++ ++void rtl_lps_leave(struct ieee80211_hw *hw) ++{ ++ struct rtl_priv *rtlpriv = rtl_priv(hw); ++ ++ if (!in_interrupt()) ++ return rtl_lps_leave_core(hw); ++ rtlpriv->enter_ps = false; ++ schedule_work(&rtlpriv->works.lps_change_work); ++} ++EXPORT_SYMBOL_GPL(rtl_lps_leave); ++ + void rtl_swlps_wq_callback(void *data) + { + struct rtl_works *rtlworks = container_of_dwork_rtl(data, diff --git a/queue-4.9/ssb-fix-error-routine-when-fallback-sprom-fails.patch b/queue-4.9/ssb-fix-error-routine-when-fallback-sprom-fails.patch new file mode 100644 index 00000000000..e46574bb973 --- /dev/null +++ b/queue-4.9/ssb-fix-error-routine-when-fallback-sprom-fails.patch @@ -0,0 +1,31 @@ +From 8052d7245b6089992343c80b38b14dbbd8354651 Mon Sep 17 00:00:00 2001 +From: Larry Finger +Date: Sat, 5 Nov 2016 14:08:57 -0500 +Subject: ssb: Fix error routine when fallback SPROM fails + +From: Larry Finger + +commit 8052d7245b6089992343c80b38b14dbbd8354651 upstream. + +When there is a CRC error in the SPROM read from the device, the code +attempts to handle a fallback SPROM. When this also fails, the driver +returns zero rather than an error code. + +Signed-off-by: Larry Finger +Signed-off-by: Kalle Valo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ssb/pci.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/ssb/pci.c ++++ b/drivers/ssb/pci.c +@@ -909,6 +909,7 @@ static int ssb_pci_sprom_get(struct ssb_ + if (err) { + ssb_warn("WARNING: Using fallback SPROM failed (err %d)\n", + err); ++ goto out_free; + } else { + ssb_dbg("Using SPROM revision %d provided by platform\n", + sprom->revision); diff --git a/queue-4.9/thermal-hwmon-properly-report-critical-temperature-in-sysfs.patch b/queue-4.9/thermal-hwmon-properly-report-critical-temperature-in-sysfs.patch new file mode 100644 index 00000000000..1d94ed76c35 --- /dev/null +++ b/queue-4.9/thermal-hwmon-properly-report-critical-temperature-in-sysfs.patch @@ -0,0 +1,45 @@ +From f37fabb8643eaf8e3b613333a72f683770c85eca Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Tue, 22 Nov 2016 19:22:44 +0200 +Subject: thermal: hwmon: Properly report critical temperature in sysfs + +From: Krzysztof Kozlowski + +commit f37fabb8643eaf8e3b613333a72f683770c85eca upstream. + +In the critical sysfs entry the thermal hwmon was returning wrong +temperature to the user-space. It was reporting the temperature of the +first trip point instead of the temperature of critical trip point. + +For example: + /sys/class/hwmon/hwmon0/temp1_crit:50000 + /sys/class/thermal/thermal_zone0/trip_point_0_temp:50000 + /sys/class/thermal/thermal_zone0/trip_point_0_type:active + /sys/class/thermal/thermal_zone0/trip_point_3_temp:120000 + /sys/class/thermal/thermal_zone0/trip_point_3_type:critical + +Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver +have been registering a sysfs entry if get_crit_temp() callback was +provided. However when accessed, it was calling get_trip_temp() instead +of the get_crit_temp(). + +Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F") +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Zhang Rui +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/thermal/thermal_hwmon.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/thermal/thermal_hwmon.c ++++ b/drivers/thermal/thermal_hwmon.c +@@ -98,7 +98,7 @@ temp_crit_show(struct device *dev, struc + int temperature; + int ret; + +- ret = tz->ops->get_trip_temp(tz, 0, &temperature); ++ ret = tz->ops->get_crit_temp(tz, &temperature); + if (ret) + return ret; + diff --git a/queue-4.9/timekeeping_force_unsigned_clocksource_to_nanoseconds_conversion.patch b/queue-4.9/timekeeping_force_unsigned_clocksource_to_nanoseconds_conversion.patch new file mode 100644 index 00000000000..63cb96d344a --- /dev/null +++ b/queue-4.9/timekeeping_force_unsigned_clocksource_to_nanoseconds_conversion.patch @@ -0,0 +1,138 @@ +From 9c1645727b8fa90d07256fdfcc45bf831242a3ab Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 8 Dec 2016 20:49:32 +0000 +Subject: timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion + +From: Thomas Gleixner + +commit 9c1645727b8fa90d07256fdfcc45bf831242a3ab upstream. + +The clocksource delta to nanoseconds conversion is using signed math, but +the delta is unsigned. This makes the conversion space smaller than +necessary and in case of a multiplication overflow the conversion can +become negative. The conversion is done with scaled math: + + s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift; + +Shifting a signed integer right obvioulsy preserves the sign, which has +interesting consequences: + + - Time jumps backwards + + - __iter_div_u64_rem() which is used in one of the calling code pathes + will take forever to piecewise calculate the seconds/nanoseconds part. + +This has been reported by several people with different scenarios: + +David observed that when stopping a VM with a debugger: + + "It was essentially the stopped by debugger case. I forget exactly why, + but the guest was being explicitly stopped from outside, it wasn't just + scheduling lag. I think it was something in the vicinity of 10 minutes + stopped." + + When lifting the stop the machine went dead. + +The stopped by debugger case is not really interesting, but nevertheless it +would be a good thing not to die completely. + +But this was also observed on a live system by Liav: + + "When the OS is too overloaded, delta will get a high enough value for the + msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so + after the shift the nsec variable will gain a value similar to + 0xffffffffff000000." + +Unfortunately this has been reintroduced recently with commit 6bd58f09e1d8 +("time: Add cycles to nanoseconds translation"). It had been fixed a year +ago already in commit 35a4933a8959 ("time: Avoid signed overflow in +timekeeping_get_ns()"). + +Though it's not surprising that the issue has been reintroduced because the +function itself and the whole call chain uses s64 for the result and the +propagation of it. The change in this recent commit is subtle: + + s64 nsec; + +- nsec = (d * m + n) >> s: ++ nsec = d * m + n; ++ nsec >>= s; + +d being type of cycle_t adds another level of obfuscation. + +This wouldn't have happened if the previous change to unsigned computation +would have made the 'nsec' variable u64 right away and a follow up patch +had cleaned up the whole call chain. + +There have been patches submitted which basically did a revert of the above +patch leaving everything else unchanged as signed. Back to square one. This +spawned a admittedly pointless discussion about potential users which rely +on the unsigned behaviour until someone pointed out that it had been fixed +before. The changelogs of said patches added further confusion as they made +finally false claims about the consequences for eventual users which expect +signed results. + +Despite delta being cycle_t, aka. u64, it's very well possible to hand in +a signed negative value and the signed computation will happily return the +correct result. But nobody actually sat down and analyzed the code which +was added as user after the propably unintended signed conversion. + +Though in sensitive code like this it's better to analyze it proper and +make sure that nothing relies on this than hunting the subtle wreckage half +a year later. After analyzing all call chains it stands that no caller can +hand in a negative value (which actually would work due to the s64 cast) +and rely on the signed math to do the right thing. + +Change the conversion function to unsigned math. The conversion of all call +chains is done in a follow up patch. + +This solves the starvation issue, which was caused by the negative result, +but it does not solve the underlying problem. It merily procrastinates +it. When the timekeeper update is deferred long enough that the unsigned +multiplication overflows, then time going backwards is observable again. + +It does neither solve the issue of clocksources with a small counter width +which will wrap around possibly several times and cause random time stamps +to be generated. But those are usually not found on systems used for +virtualization, so this is likely a non issue. + +I took the liberty to claim authorship for this simply because +analyzing all callsites and writing the changelog took substantially +more time than just making the simple s/s64/u64/ change and ignore the +rest. + +Fixes: 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation") +Reported-by: David Gibson +Reported-by: Liav Rehana +Signed-off-by: Thomas Gleixner +Reviewed-by: David Gibson +Acked-by: Peter Zijlstra (Intel) +Cc: Parit Bhargava +Cc: Laurent Vivier +Cc: "Christopher S. Hall" +Cc: Chris Metcalf +Cc: Richard Cochran +Cc: John Stultz +Link: http://lkml.kernel.org/r/20161208204228.688545601@linutronix.de +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/time/timekeeping.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/time/timekeeping.c ++++ b/kernel/time/timekeeping.c +@@ -299,10 +299,10 @@ u32 (*arch_gettimeoffset)(void) = defaul + static inline u32 arch_gettimeoffset(void) { return 0; } + #endif + +-static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr, ++static inline u64 timekeeping_delta_to_ns(struct tk_read_base *tkr, + cycle_t delta) + { +- s64 nsec; ++ u64 nsec; + + nsec = delta * tkr->mult + tkr->xtime_nsec; + nsec >>= tkr->shift; -- 2.47.3