From: Greg Kroah-Hartman Date: Tue, 3 Jun 2014 22:56:41 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v3.14.6~63 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=5081fce81644fca7c613b4642c787dc835590f0d;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: brcmsmac-fix-deadlock-on-missing-firmware.patch documentation-update-stable-address-in-chinese-and-japanese-translations.patch drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch leds-leds-pwm-properly-clean-up-after-probe-failure.patch rtl8192cu-fix-unbalanced-irq-enable-in-error-path-of-rtl92cu_hw_init.patch --- diff --git a/queue-3.10/brcmsmac-fix-deadlock-on-missing-firmware.patch b/queue-3.10/brcmsmac-fix-deadlock-on-missing-firmware.patch new file mode 100644 index 00000000000..ff6801cacbc --- /dev/null +++ b/queue-3.10/brcmsmac-fix-deadlock-on-missing-firmware.patch @@ -0,0 +1,83 @@ +From 8fc1e8c240aab968db658b2d8d079b4391207a36 Mon Sep 17 00:00:00 2001 +From: Emil Goode +Date: Sun, 9 Mar 2014 21:06:51 +0100 +Subject: brcmsmac: fix deadlock on missing firmware + +From: Emil Goode + +commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream. + +When brcm80211 firmware is not installed networking hangs. +A deadlock happens because we call ieee80211_unregister_hw() +from the .start callback of struct ieee80211_ops. When .start +is called we are under rtnl lock and ieee80211_unregister_hw() +tries to take it again. + +Function call stack: + +dev_change_flags() + __dev_change_flags() + __dev_open() + ASSERT_RTNL() <-- Assert rtnl lock + ops->ndo_open() + +.ndo_open = ieee80211_open, + +ieee80211_open() + ieee80211_do_open() + drv_start() + local->ops->start() + +.start = brcms_ops_start, + +brcms_ops_start() + brcms_remove() + ieee80211_unregister_hw() + rtnl_lock() <-- Here we deadlock + +Introduced by: +commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e +("brcmsmac: request firmware in .start() callback") + +This patch fixes the bug by removing the call to brcms_remove() +and moves the brcms_request_fw() call to the top of the .start +callback to not initiate anything unless firmware is installed. + +Signed-off-by: Emil Goode +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 14 ++++++-------- + 1 file changed, 6 insertions(+), 8 deletions(-) + +--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c ++++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c +@@ -426,6 +426,12 @@ static int brcms_ops_start(struct ieee80 + bool blocked; + int err; + ++ if (!wl->ucode.bcm43xx_bomminor) { ++ err = brcms_request_fw(wl, wl->wlc->hw->d11core); ++ if (err) ++ return -ENOENT; ++ } ++ + ieee80211_wake_queues(hw); + spin_lock_bh(&wl->lock); + blocked = brcms_rfkill_set_hw_state(wl); +@@ -433,14 +439,6 @@ static int brcms_ops_start(struct ieee80 + if (!blocked) + wiphy_rfkill_stop_polling(wl->pub->ieee_hw->wiphy); + +- if (!wl->ucode.bcm43xx_bomminor) { +- err = brcms_request_fw(wl, wl->wlc->hw->d11core); +- if (err) { +- brcms_remove(wl->wlc->hw->d11core); +- return -ENOENT; +- } +- } +- + spin_lock_bh(&wl->lock); + /* avoid acknowledging frames before a non-monitor device is added */ + wl->mute_tx = true; diff --git a/queue-3.10/documentation-update-stable-address-in-chinese-and-japanese-translations.patch b/queue-3.10/documentation-update-stable-address-in-chinese-and-japanese-translations.patch new file mode 100644 index 00000000000..c1f10ecdec6 --- /dev/null +++ b/queue-3.10/documentation-update-stable-address-in-chinese-and-japanese-translations.patch @@ -0,0 +1,78 @@ +From 98b0f811aade1b7c6e7806c86aa0befd5919d65f Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Mon, 14 Apr 2014 18:52:14 +0200 +Subject: Documentation: Update stable address in Chinese and Japanese translations + +From: Geert Uytterhoeven + +commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream. + +The English and Korean translations were updated, the Chinese and Japanese +weren't. + +Signed-off-by: Geert Uytterhoeven +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/ja_JP/HOWTO | 2 +- + Documentation/ja_JP/stable_kernel_rules.txt | 6 +++--- + Documentation/zh_CN/HOWTO | 2 +- + Documentation/zh_CN/stable_kernel_rules.txt | 2 +- + 4 files changed, 6 insertions(+), 6 deletions(-) + +--- a/Documentation/ja_JP/HOWTO ++++ b/Documentation/ja_JP/HOWTO +@@ -315,7 +315,7 @@ Andrew Morton が Linux-kernel メーリ + もし、2.6.x.y カーネルが存在しない場合には、番号が一番大きい 2.6.x が + 最新の安定版カーネルです。 + +-2.6.x.y は "stable" チーム でメンテされており、必 ++2.6.x.y は "stable" チーム でメンテされており、必 + 要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ + た問題がなければもう少し長くなることもあります。セキュリティ関連の問題 + の場合はこれに対してだいたいの場合、すぐにリリースがされます。 +--- a/Documentation/ja_JP/stable_kernel_rules.txt ++++ b/Documentation/ja_JP/stable_kernel_rules.txt +@@ -50,16 +50,16 @@ linux-2.6.29/Documentation/stable_kernel + + -stable ツリーにパッチを送付する手続き- + +- - 上記の規則に従っているかを確認した後に、stable@kernel.org にパッチ ++ - 上記の規則に従っているかを確認した後に、stable@vger.kernel.org にパッチ + を送る。 + - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合 + には NAK を受け取る。この反応は開発者たちのスケジュールによって、数 + 日かかる場合がある。 + - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの + メンテナーによるレビューのために -stable キューに追加される。 +- - パッチに stable@kernel.org のアドレスが付加されているときには、それ ++ - パッチに stable@vger.kernel.org のアドレスが付加されているときには、それ + が Linus のツリーに入る時に自動的に stable チームに email される。 +- - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ ++ - セキュリティパッチはこのエイリアス (stable@vger.kernel.org) に送られるべ + きではなく、代わりに security@kernel.org のアドレスに送られる。 + + レビューサイクル- +--- a/Documentation/zh_CN/HOWTO ++++ b/Documentation/zh_CN/HOWTO +@@ -237,7 +237,7 @@ kernel.org网站的pub/linux/kernel/v2.6 + 如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定 + 版内核。 + +-2.6.x.y版本由“稳定版”小组（邮件地址）维护，一般隔周发 ++2.6.x.y版本由“稳定版”小组（邮件地址）维护，一般隔周发 + 布新版本。 + + 内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定 +--- a/Documentation/zh_CN/stable_kernel_rules.txt ++++ b/Documentation/zh_CN/stable_kernel_rules.txt +@@ -42,7 +42,7 @@ Documentation/stable_kernel_rules.txt çš + + 向稳定版代码树提交补丁的过程： + +- - 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。 ++ - 在确认了补丁符合以上的规则后，将补丁发送到stable@vger.kernel.org。 + - 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收 + 到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。 + - 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。 diff --git a/queue-3.10/drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch b/queue-3.10/drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch new file mode 100644 index 00000000000..94f5c17940d --- /dev/null +++ b/queue-3.10/drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch @@ -0,0 +1,36 @@ +From a3d0b1218d351c6e6f3cea36abe22236a08cb246 Mon Sep 17 00:00:00 2001 +From: Ilia Mirkin +Date: Wed, 26 Mar 2014 19:37:21 -0400 +Subject: drm/nouveau/acpi: allow non-optimus setups to load vbios from acpi + +From: Ilia Mirkin + +commit a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream. + +There appear to be a crop of new hardware where the vbios is not +available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. +The data read from PCIROM almost invariably contains invalid +instructions (still has the x86 opcodes), which makes this a low-risk +way to try to obtain a valid vbios image. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 +Signed-off-by: Ilia Mirkin +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c ++++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c +@@ -372,9 +372,6 @@ bool nouveau_acpi_rom_supported(struct p + acpi_status status; + acpi_handle dhandle, rom_handle; + +- if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected) +- return false; +- + dhandle = DEVICE_ACPI_HANDLE(&pdev->dev); + if (!dhandle) + return false; diff --git a/queue-3.10/drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch b/queue-3.10/drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch new file mode 100644 index 00000000000..ea2dc898010 --- /dev/null +++ b/queue-3.10/drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch @@ -0,0 +1,72 @@ +From 61679fe153b2b9ea5b5e2ab93305419e85e99a9d Mon Sep 17 00:00:00 2001 +From: Martin Peres +Date: Fri, 14 Mar 2014 00:26:52 +0100 +Subject: drm/nouveau/pm/fan: drop the fan lock in fan_update() before rescheduling +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Martin Peres + +commit 61679fe153b2b9ea5b5e2ab93305419e85e99a9d upstream. + +This should fix a deadlock that has been reported to us where fan_update() +would hold the fan lock and try to grab the alarm_program_lock to reschedule +an update. On an other CPU, the alarm_program_lock would have been taken +before calling fan_update(), leading to a deadlock. + +We should Cc: # 3.9+ + +Reported-by: Marcin Slusarz +Tested-by: Timothée Ravier +Tested-by: Boris Fersing (IRC nick fersingb, no public email address) +Signed-off-by: Martin Peres +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/core/subdev/therm/fan.c | 19 +++++++++++++------ + 1 file changed, 13 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/nouveau/core/subdev/therm/fan.c ++++ b/drivers/gpu/drm/nouveau/core/subdev/therm/fan.c +@@ -54,8 +54,10 @@ nouveau_fan_update(struct nouveau_fan *f + + /* check that we're not already at the target duty cycle */ + duty = fan->get(therm); +- if (duty == target) +- goto done; ++ if (duty == target) { ++ spin_unlock_irqrestore(&fan->lock, flags); ++ return 0; ++ } + + /* smooth out the fanspeed increase/decrease */ + if (!immediate && duty >= 0) { +@@ -73,8 +75,15 @@ nouveau_fan_update(struct nouveau_fan *f + + nv_debug(therm, "FAN update: %d\n", duty); + ret = fan->set(therm, duty); +- if (ret) +- goto done; ++ if (ret) { ++ spin_unlock_irqrestore(&fan->lock, flags); ++ return ret; ++ } ++ ++ /* fan speed updated, drop the fan lock before grabbing the ++ * alarm-scheduling lock and risking a deadlock ++ */ ++ spin_unlock_irqrestore(&fan->lock, flags); + + /* schedule next fan update, if not at target speed already */ + if (list_empty(&fan->alarm.head) && target != duty) { +@@ -92,8 +101,6 @@ nouveau_fan_update(struct nouveau_fan *f + ptimer->alarm(ptimer, delay * 1000 * 1000, &fan->alarm); + } + +-done: +- spin_unlock_irqrestore(&fan->lock, flags); + return ret; + } + diff --git a/queue-3.10/leds-leds-pwm-properly-clean-up-after-probe-failure.patch b/queue-3.10/leds-leds-pwm-properly-clean-up-after-probe-failure.patch new file mode 100644 index 00000000000..373cb3c3c11 --- /dev/null +++ b/queue-3.10/leds-leds-pwm-properly-clean-up-after-probe-failure.patch @@ -0,0 +1,85 @@ +From 392369019eb96e914234ea21eda806cb51a1073e Mon Sep 17 00:00:00 2001 +From: Russell King +Date: Sun, 6 Apr 2014 15:20:03 -0700 +Subject: leds: leds-pwm: properly clean up after probe failure + +From: Russell King + +commit 392369019eb96e914234ea21eda806cb51a1073e upstream. + +When probing with DT, we add each LED one at a time. If we find a LED +without a PWM device (because it is not available yet) we fail the +initialisation, unregister previous LEDs, and then by way of managed +resources, we free the structure. + +The problem with this is we may have a scheduled and active work_struct +in this structure, and this results in a nasty kernel oops. + +We need to cancel this work_struct properly upon cleanup - and the +cleanup we require is the same cleanup as we do when the LED platform +device is removed. Rather than writing this same code three times, +move it into a separate function and use it in all three places. + +Fixes: c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep") +Signed-off-by: Russell King +Signed-off-by: Bryan Wu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/leds/leds-pwm.c | 23 +++++++++++++---------- + 1 file changed, 13 insertions(+), 10 deletions(-) + +--- a/drivers/leds/leds-pwm.c ++++ b/drivers/leds/leds-pwm.c +@@ -82,6 +82,15 @@ static inline size_t sizeof_pwm_leds_pri + (sizeof(struct led_pwm_data) * num_leds); + } + ++static void led_pwm_cleanup(struct led_pwm_priv *priv) ++{ ++ while (priv->num_leds--) { ++ led_classdev_unregister(&priv->leds[priv->num_leds].cdev); ++ if (priv->leds[priv->num_leds].can_sleep) ++ cancel_work_sync(&priv->leds[priv->num_leds].work); ++ } ++} ++ + static struct led_pwm_priv *led_pwm_create_of(struct platform_device *pdev) + { + struct device_node *node = pdev->dev.of_node; +@@ -139,8 +148,7 @@ static struct led_pwm_priv *led_pwm_crea + + return priv; + err: +- while (priv->num_leds--) +- led_classdev_unregister(&priv->leds[priv->num_leds].cdev); ++ led_pwm_cleanup(priv); + + return NULL; + } +@@ -200,8 +208,8 @@ static int led_pwm_probe(struct platform + return 0; + + err: +- while (i--) +- led_classdev_unregister(&priv->leds[i].cdev); ++ priv->num_leds = i; ++ led_pwm_cleanup(priv); + + return ret; + } +@@ -209,13 +217,8 @@ err: + static int led_pwm_remove(struct platform_device *pdev) + { + struct led_pwm_priv *priv = platform_get_drvdata(pdev); +- int i; + +- for (i = 0; i < priv->num_leds; i++) { +- led_classdev_unregister(&priv->leds[i].cdev); +- if (priv->leds[i].can_sleep) +- cancel_work_sync(&priv->leds[i].work); +- } ++ led_pwm_cleanup(priv); + + return 0; + } diff --git a/queue-3.10/rtl8192cu-fix-unbalanced-irq-enable-in-error-path-of-rtl92cu_hw_init.patch b/queue-3.10/rtl8192cu-fix-unbalanced-irq-enable-in-error-path-of-rtl92cu_hw_init.patch new file mode 100644 index 00000000000..5670c5fad06 --- /dev/null +++ b/queue-3.10/rtl8192cu-fix-unbalanced-irq-enable-in-error-path-of-rtl92cu_hw_init.patch @@ -0,0 +1,29 @@ +From 3234f5b06fc3094176a86772cc64baf3decc98fc Mon Sep 17 00:00:00 2001 +From: Ben Hutchings +Date: Sat, 26 Apr 2014 21:59:04 +0100 +Subject: rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init() + +From: Ben Hutchings + +commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream. + +Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') +Signed-off-by: Ben Hutchings +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c ++++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c +@@ -1001,7 +1001,7 @@ int rtl92cu_hw_init(struct ieee80211_hw + err = _rtl92cu_init_mac(hw); + if (err) { + RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "init mac failed!\n"); +- return err; ++ goto exit; + } + err = rtl92c_download_fw(hw); + if (err) { diff --git a/queue-3.10/series b/queue-3.10/series index 80a2d759293..48aec92781d 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -48,3 +48,9 @@ posix_acl-handle-null-acl-in-posix_acl_equiv_mode.patch omap3isp-defer-probe-when-the-iommu-is-not-available.patch arm-dts-i.mx53-fix-ipu-register-space-size.patch arm-8012-1-kdump-avoid-overflow-when-converting-pfn-to-physaddr.patch +rtl8192cu-fix-unbalanced-irq-enable-in-error-path-of-rtl92cu_hw_init.patch +drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch +drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch +leds-leds-pwm-properly-clean-up-after-probe-failure.patch +brcmsmac-fix-deadlock-on-missing-firmware.patch +documentation-update-stable-address-in-chinese-and-japanese-translations.patch