From: Greg Kroah-Hartman Date: Tue, 3 Jun 2014 22:56:46 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v3.14.6~62 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4fad0cab9b0cdcefb36f0ff3be06db0cf9dccf5c;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: brcmsmac-fix-deadlock-on-missing-firmware.patch documentation-update-stable-address-in-chinese-and-japanese-translations.patch drm-i915-restore-backlight-precision-when-converting-from-acpi.patch drm-i915-vlv-reset-vlv-media-force-wake-request-register.patch drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch drm-nouveau-fix-another-lock-unbalance-in-nouveau_crtc_page_flip.patch drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch i40e-potential-array-underflow-in-i40e_vc_process_vf_msg.patch igb-fix-null-pointer-dereference-in-igb_reset_q_vector.patch igb-unset-igb_flag_has_msix-flag-when-falling-back-to-msi-only.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.14/brcmsmac-fix-deadlock-on-missing-firmware.patch b/queue-3.14/brcmsmac-fix-deadlock-on-missing-firmware.patch new file mode 100644 index 00000000000..ff6801cacbc --- /dev/null +++ b/queue-3.14/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.14/documentation-update-stable-address-in-chinese-and-japanese-translations.patch b/queue-3.14/documentation-update-stable-address-in-chinese-and-japanese-translations.patch new file mode 100644 index 00000000000..cacbbb6897c --- /dev/null +++ b/queue-3.14/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 メーリ + もし、3.x.y カーネルが存在しない場合には、番号が一番大きい 3.x が + 最新の安定版カーネルです。 + +-3.x.y は "stable" チーム でメンテされており、必 ++3.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.14/drm-i915-restore-backlight-precision-when-converting-from-acpi.patch b/queue-3.14/drm-i915-restore-backlight-precision-when-converting-from-acpi.patch new file mode 100644 index 00000000000..d47f389c958 --- /dev/null +++ b/queue-3.14/drm-i915-restore-backlight-precision-when-converting-from-acpi.patch @@ -0,0 +1,59 @@ +From 721e82c08c1afd6b47367b0e0c4a62140b0667f3 Mon Sep 17 00:00:00 2001 +From: Aaron Lu +Date: Mon, 12 May 2014 16:55:45 +0800 +Subject: drm/i915: restore backlight precision when converting from ACPI + +From: Aaron Lu + +commit 721e82c08c1afd6b47367b0e0c4a62140b0667f3 upstream. + +When we set backlight on behalf of ACPI opregion, we will convert the +backlight value in the 0-255 range defined in opregion to the actual +hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow +when doing scale) is meant to fix the overflow problem when doing the +conversion, but it also caused a problem that the converted hardware +level doesn't quite represent the intended value: say user wants maximum +backlight level(255 in opregion's range), then we will calculate the +actual hardware level to be: level = freq / max * level, where freq is +the hardware's max backlight level(937 on an user's box), and max and +level are all 255. The converted value should be 937 but the above +calculation will yield 765. + +To fix this issue, just use 64 bits to do the calculation to keep the +precision and avoid overflow at the same time. + +Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 +Reported-by: Nico Schottelius +Reviewed-by: Chris Wilson +Signed-off-by: Aaron Lu +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_panel.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_panel.c ++++ b/drivers/gpu/drm/i915/intel_panel.c +@@ -501,6 +501,7 @@ void intel_panel_set_backlight(struct in + enum pipe pipe = intel_get_pipe_from_connector(connector); + u32 freq; + unsigned long flags; ++ u64 n; + + if (!panel->backlight.present || pipe == INVALID_PIPE) + return; +@@ -511,10 +512,9 @@ void intel_panel_set_backlight(struct in + + /* scale to hardware max, but be careful to not overflow */ + freq = panel->backlight.max; +- if (freq < max) +- level = level * freq / max; +- else +- level = freq / max * level; ++ n = (u64)level * freq; ++ do_div(n, max); ++ level = n; + + panel->backlight.level = level; + if (panel->backlight.device) diff --git a/queue-3.14/drm-i915-vlv-reset-vlv-media-force-wake-request-register.patch b/queue-3.14/drm-i915-vlv-reset-vlv-media-force-wake-request-register.patch new file mode 100644 index 00000000000..eefcb812e8b --- /dev/null +++ b/queue-3.14/drm-i915-vlv-reset-vlv-media-force-wake-request-register.patch @@ -0,0 +1,39 @@ +From 05adaf1f101f25f40f12c29403e6488f0e45f6b6 Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Fri, 9 May 2014 14:52:34 +0300 +Subject: drm/i915/vlv: reset VLV media force wake request register + +From: Jani Nikula + +commit 05adaf1f101f25f40f12c29403e6488f0e45f6b6 upstream. + +Media force wake get hangs the machine when the system is booted without +displays attached. The assumption is that (at least some versions of) +the firmware has skipped some initialization in that case. + +Empirical evidence suggests we need to reset the media force wake +request register in addition to the render one to avoid hangs. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895 +Reported-by: Imre Deak +Reported-by: Darren Hart +Tested-by: Darren Hart +Reviewed-by: Mika Kuoppala +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_uncore.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/i915/intel_uncore.c ++++ b/drivers/gpu/drm/i915/intel_uncore.c +@@ -177,6 +177,8 @@ static void vlv_force_wake_reset(struct + { + __raw_i915_write32(dev_priv, FORCEWAKE_VLV, + _MASKED_BIT_DISABLE(0xffff)); ++ __raw_i915_write32(dev_priv, FORCEWAKE_MEDIA_VLV, ++ _MASKED_BIT_DISABLE(0xffff)); + /* something from same cacheline, but !FORCEWAKE_VLV */ + __raw_posting_read(dev_priv, FORCEWAKE_ACK_VLV); + } diff --git a/queue-3.14/drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch b/queue-3.14/drm-nouveau-acpi-allow-non-optimus-setups-to-load-vbios-from-acpi.patch new file mode 100644 index 00000000000..b38f10bf4b1 --- /dev/null +++ b/queue-3.14/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 +@@ -389,9 +389,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 = ACPI_HANDLE(&pdev->dev); + if (!dhandle) + return false; diff --git a/queue-3.14/drm-nouveau-fix-another-lock-unbalance-in-nouveau_crtc_page_flip.patch b/queue-3.14/drm-nouveau-fix-another-lock-unbalance-in-nouveau_crtc_page_flip.patch new file mode 100644 index 00000000000..1520156a737 --- /dev/null +++ b/queue-3.14/drm-nouveau-fix-another-lock-unbalance-in-nouveau_crtc_page_flip.patch @@ -0,0 +1,34 @@ +From 806cbc5026933a781b66adecf6d1658fde9138e6 Mon Sep 17 00:00:00 2001 +From: Maarten Lankhorst +Date: Thu, 1 May 2014 13:58:05 +0200 +Subject: drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip + +From: Maarten Lankhorst + +commit 806cbc5026933a781b66adecf6d1658fde9138e6 upstream. + +Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking +issues in page flipping paths". chan->cli->mutex is unlocked a second time +in the fail_unreserve path, fix this by moving mutex_unlock down. + +Signed-off-by: Maarten Lankhorst +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_display.c ++++ b/drivers/gpu/drm/nouveau/nouveau_display.c +@@ -762,9 +762,9 @@ nouveau_crtc_page_flip(struct drm_crtc * + } + + ret = nouveau_page_flip_emit(chan, old_bo, new_bo, s, &fence); +- mutex_unlock(&chan->cli->mutex); + if (ret) + goto fail_unreserve; ++ mutex_unlock(&chan->cli->mutex); + + /* Update the crtc struct and cleanup */ + crtc->fb = fb; diff --git a/queue-3.14/drm-nouveau-pm-fan-drop-the-fan-lock-in-fan_update-before-rescheduling.patch b/queue-3.14/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.14/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.14/i40e-potential-array-underflow-in-i40e_vc_process_vf_msg.patch b/queue-3.14/i40e-potential-array-underflow-in-i40e_vc_process_vf_msg.patch new file mode 100644 index 00000000000..08e7147d6f8 --- /dev/null +++ b/queue-3.14/i40e-potential-array-underflow-in-i40e_vc_process_vf_msg.patch @@ -0,0 +1,35 @@ +From c243e96335c56e56dcf6a00593104554fb06b689 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Wed, 15 Jan 2014 06:43:39 +0000 +Subject: i40e: potential array underflow in i40e_vc_process_vf_msg() + +From: Dan Carpenter + +commit c243e96335c56e56dcf6a00593104554fb06b689 upstream. + +If "vf_id" is smaller than hw->func_caps.vf_base_id then it leads to +an array underflow of the pf->vf[] array. This is unlikely to happen +unless the hardware is bad, but it's a small change and it silences a +static checker warning. + +Fixes: 7efa84b7abc1 ('i40e: support VFs on PFs other than 0') +Signed-off-by: Dan Carpenter +Tested-by: Sibai Li +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c ++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +@@ -1776,7 +1776,7 @@ int i40e_vc_process_vf_msg(struct i40e_p + u32 v_retval, u8 *msg, u16 msglen) + { + struct i40e_hw *hw = &pf->hw; +- int local_vf_id = vf_id - hw->func_caps.vf_base_id; ++ unsigned int local_vf_id = vf_id - hw->func_caps.vf_base_id; + struct i40e_vf *vf; + int ret; + diff --git a/queue-3.14/igb-fix-null-pointer-dereference-in-igb_reset_q_vector.patch b/queue-3.14/igb-fix-null-pointer-dereference-in-igb_reset_q_vector.patch new file mode 100644 index 00000000000..3b518797833 --- /dev/null +++ b/queue-3.14/igb-fix-null-pointer-dereference-in-igb_reset_q_vector.patch @@ -0,0 +1,46 @@ +From cb06d102327eadcd1bdc480bfd9f8876251d1007 Mon Sep 17 00:00:00 2001 +From: Christoph Paasch +Date: Fri, 21 Mar 2014 03:48:19 -0700 +Subject: igb: Fix Null-pointer dereference in igb_reset_q_vector + +From: Christoph Paasch + +commit cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream. + +When igb_set_interrupt_capability() calls +igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset), +num_q_vectors has been set but no vector has yet been allocated. + +igb_reset_interrupt_capability() will then call igb_reset_q_vector, +which assumes that the vector is allocated. As this is not the case, we +are accessing a NULL-pointer. + +This patch fixes it by checking that q_vector is indeed different from +NULL. + +Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime) +Cc: Carolyn Wyborny +Signed-off-by: Christoph Paasch +Tested-by: Jeff Pieper +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/intel/igb/igb_main.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/net/ethernet/intel/igb/igb_main.c ++++ b/drivers/net/ethernet/intel/igb/igb_main.c +@@ -1014,6 +1014,12 @@ static void igb_reset_q_vector(struct ig + { + struct igb_q_vector *q_vector = adapter->q_vector[v_idx]; + ++ /* Coming from igb_set_interrupt_capability, the vectors are not yet ++ * allocated. So, q_vector is NULL so we should stop here. ++ */ ++ if (!q_vector) ++ return; ++ + if (q_vector->tx.ring) + adapter->tx_ring[q_vector->tx.ring->queue_index] = NULL; + diff --git a/queue-3.14/igb-unset-igb_flag_has_msix-flag-when-falling-back-to-msi-only.patch b/queue-3.14/igb-unset-igb_flag_has_msix-flag-when-falling-back-to-msi-only.patch new file mode 100644 index 00000000000..0da6286b95b --- /dev/null +++ b/queue-3.14/igb-unset-igb_flag_has_msix-flag-when-falling-back-to-msi-only.patch @@ -0,0 +1,95 @@ +From b709323d2477614823a38c2f2a9a206e087e28fc Mon Sep 17 00:00:00 2001 +From: Christoph Paasch +Date: Fri, 21 Mar 2014 04:02:09 -0700 +Subject: igb: Unset IGB_FLAG_HAS_MSIX-flag when falling back to msi-only + +From: Christoph Paasch + +commit b709323d2477614823a38c2f2a9a206e087e28fc upstream. + +Prior to cd14ef54d25 (igb: Change to use statically allocated array for +MSIx entries), having msix_entries different from NULL was an indicator +that MSIX is enabled. +In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to +the above patch msix_entries was set to NULL by +igb_reset_interrupt_capability. + +However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the +stack gets completly confused: + +[ 42.659791] ------------[ cut here ]------------ +[ 42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb() +[ 42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out +[ 42.923253] Modules linked in: +[ 42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437 +[ 43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 +[ 43.119215] 0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108 +[ 43.208165] ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8 +[ 43.297120] ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008 +[ 43.386071] Call Trace: +[ 43.415303] [] dump_stack+0x49/0x62 +[ 43.484174] [] warn_slowpath_common+0x77/0x91 +[ 43.556049] [] ? dev_watchdog+0x15c/0x1fb +[ 43.623759] [] warn_slowpath_fmt+0x41/0x43 +[ 43.692511] [] dev_watchdog+0x15c/0x1fb +[ 43.758141] [] ? __netdev_watchdog_up+0x64/0x64 +[ 43.832091] [] call_timer_fn+0x17/0x6f +[ 43.896682] [] run_timer_softirq+0x162/0x1a2 +[ 43.967511] [] __do_softirq+0xcd/0x1cc +[ 44.032104] [] irq_exit+0x3a/0x48 +[ 44.091492] [] smp_apic_timer_interrupt+0x43/0x50 +[ 44.167525] [] apic_timer_interrupt+0x6a/0x70 +[ 44.239392] [] ? default_idle+0x6/0x8 +[ 44.310343] [] arch_cpu_idle+0x13/0x18 +[ 44.374934] [] cpu_startup_entry+0xa7/0x101 +[ 44.444724] [] start_secondary+0x1b2/0x1b7 +[ 44.513472] ---[ end trace a5a075fd4e7f854f ]--- +[ 44.568753] igb 0000:04:00.0 eth0: Reset adapter +[ 46.206945] random: nonblocking pool is initialized +[ 46.465670] irq 44: nobody cared (try booting with the "irqpoll" option) +[ 46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G W 3.14.0-rc2-mptcp #437 +[ 46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011 +[ 46.716641] ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d +[ 46.805598] ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400 +[ 46.894539] ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8 +[ 46.983484] Call Trace: +[ 47.012714] [] dump_stack+0x49/0x62 +[ 47.081585] [] __report_bad_irq+0x35/0xc1 +[ 47.149295] [] note_interrupt+0x16e/0x1ea +[ 47.217006] [] handle_irq_event_percpu+0x116/0x12e +[ 47.294075] [] handle_irq_event+0x33/0x4f +[ 47.361787] [] handle_fasteoi_irq+0x83/0xd1 +[ 47.431577] [] handle_irq+0x1f/0x28 +[ 47.493047] [] do_IRQ+0x4e/0xd4 +[ 47.550358] [] common_interrupt+0x6a/0x6a +[ 47.618066] [] ? default_idle+0x6/0x8 +[ 47.689016] [] arch_cpu_idle+0x13/0x18 +[ 47.753605] [] cpu_startup_entry+0xa7/0x101 +[ 47.823397] [] start_secondary+0x1b2/0x1b7 +[ 47.892146] handlers: +[ 47.919301] [] igb_intr + +So, this patch unsets the flag to indicate that we are not using MSIX. +This patch does exactly this: Unsetting the flag when falling back to MSI. + +Fixes: cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries) +Cc: Carolyn Wyborny +Signed-off-by: Christoph Paasch +Tested-by: Jeff Pieper +Signed-off-by: Jeff Kirsher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/intel/igb/igb_main.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/ethernet/intel/igb/igb_main.c ++++ b/drivers/net/ethernet/intel/igb/igb_main.c +@@ -1127,6 +1127,7 @@ static void igb_set_interrupt_capability + + /* If we can't do MSI-X, try MSI */ + msi_only: ++ adapter->flags &= ~IGB_FLAG_HAS_MSIX; + #ifdef CONFIG_PCI_IOV + /* disable SR-IOV for non MSI-X configurations */ + if (adapter->vf_data) { diff --git a/queue-3.14/leds-leds-pwm-properly-clean-up-after-probe-failure.patch b/queue-3.14/leds-leds-pwm-properly-clean-up-after-probe-failure.patch new file mode 100644 index 00000000000..1f841ac7575 --- /dev/null +++ b/queue-3.14/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 +@@ -84,6 +84,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 int led_pwm_create_of(struct platform_device *pdev, + struct led_pwm_priv *priv) + { +@@ -131,8 +140,7 @@ static int led_pwm_create_of(struct plat + + return 0; + err: +- while (priv->num_leds--) +- led_classdev_unregister(&priv->leds[priv->num_leds].cdev); ++ led_pwm_cleanup(priv); + + return ret; + } +@@ -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.14/rtl8192cu-fix-unbalanced-irq-enable-in-error-path-of-rtl92cu_hw_init.patch b/queue-3.14/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.14/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.14/series b/queue-3.14/series index 524d68ea4fd..a948e627872 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -110,3 +110,15 @@ arm-mvebu-fix-nor-bus-width-in-armada-xp-db-device-tree.patch arm-mvebu-fix-nor-bus-width-in-armada-xp-openblocks-ax3-device-tree.patch arm-dts-fix-missing-device_type-memory-for-ste-ccu8540.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-fix-another-lock-unbalance-in-nouveau_crtc_page_flip.patch +drm-i915-vlv-reset-vlv-media-force-wake-request-register.patch +drm-i915-restore-backlight-precision-when-converting-from-acpi.patch +i40e-potential-array-underflow-in-i40e_vc_process_vf_msg.patch +igb-fix-null-pointer-dereference-in-igb_reset_q_vector.patch +igb-unset-igb_flag_has_msix-flag-when-falling-back-to-msi-only.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