--- /dev/null
+From 8fc1e8c240aab968db658b2d8d079b4391207a36 Mon Sep 17 00:00:00 2001
+From: Emil Goode <emilgoode@gmail.com>
+Date: Sun, 9 Mar 2014 21:06:51 +0100
+Subject: brcmsmac: fix deadlock on missing firmware
+
+From: Emil Goode <emilgoode@gmail.com>
+
+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 <emilgoode@gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 98b0f811aade1b7c6e7806c86aa0befd5919d65f Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Mon, 14 Apr 2014 18:52:14 +0200
+Subject: Documentation: Update stable address in Chinese and Japanese translations
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream.
+
+The English and Korean translations were updated, the Chinese and Japanese
+weren't.
+
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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" チーム <stable@kernel.org> でメンテされており、必
++3.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、必
+ 要に応じてリリースされます。通常のリリース期間は 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版本由“稳定版”小组（邮件地址<stable@kernel.org>）维护，一般隔周发
++2.6.x.y版本由“稳定版”小组（邮件地址<stable@vger.kernel.org>）维护，一般隔周发
+ 布新版本。
+
+ 内核源码中的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 ç\9a
+
+ 向稳定版代码树提交补丁的过程：
+
+- - 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。
++ - 在确认了补丁符合以上的规则后，将补丁发送到stable@vger.kernel.org。
+ - 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收
+ 到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。
+ - 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。
--- /dev/null
+From 721e82c08c1afd6b47367b0e0c4a62140b0667f3 Mon Sep 17 00:00:00 2001
+From: Aaron Lu <aaron.lu@intel.com>
+Date: Mon, 12 May 2014 16:55:45 +0800
+Subject: drm/i915: restore backlight precision when converting from ACPI
+
+From: Aaron Lu <aaron.lu@intel.com>
+
+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 <nico-bugzilla.kernel.org@schottelius.org>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Aaron Lu <aaron.lu@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 05adaf1f101f25f40f12c29403e6488f0e45f6b6 Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Fri, 9 May 2014 14:52:34 +0300
+Subject: drm/i915/vlv: reset VLV media force wake request register
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+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 <imre.deak@intel.com>
+Reported-by: Darren Hart <dvhart@linux.intel.com>
+Tested-by: Darren Hart <dvhart@linux.intel.com>
+Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From a3d0b1218d351c6e6f3cea36abe22236a08cb246 Mon Sep 17 00:00:00 2001
+From: Ilia Mirkin <imirkin@alum.mit.edu>
+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 <imirkin@alum.mit.edu>
+
+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 <imirkin@alum.mit.edu>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 806cbc5026933a781b66adecf6d1658fde9138e6 Mon Sep 17 00:00:00 2001
+From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
+Date: Thu, 1 May 2014 13:58:05 +0200
+Subject: drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip
+
+From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
+
+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 <maarten.lankhorst@canonical.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 61679fe153b2b9ea5b5e2ab93305419e85e99a9d Mon Sep 17 00:00:00 2001
+From: Martin Peres <martin.peres@labri.fr>
+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 <martin.peres@labri.fr>
+
+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: <stable@vger.kernel.org> # 3.9+
+
+Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
+Tested-by: Timothée Ravier <tim@siosm.fr>
+Tested-by: Boris Fersing (IRC nick fersingb, no public email address)
+Signed-off-by: Martin Peres <martin.peres@free.fr>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From c243e96335c56e56dcf6a00593104554fb06b689 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 15 Jan 2014 06:43:39 +0000
+Subject: i40e: potential array underflow in i40e_vc_process_vf_msg()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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 <dan.carpenter@oracle.com>
+Tested-by: Sibai Li <sibai.li@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From cb06d102327eadcd1bdc480bfd9f8876251d1007 Mon Sep 17 00:00:00 2001
+From: Christoph Paasch <christoph.paasch@uclouvain.be>
+Date: Fri, 21 Mar 2014 03:48:19 -0700
+Subject: igb: Fix Null-pointer dereference in igb_reset_q_vector
+
+From: Christoph Paasch <christoph.paasch@uclouvain.be>
+
+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 <carolyn.wyborny@intel.com>
+Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
+Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From b709323d2477614823a38c2f2a9a206e087e28fc Mon Sep 17 00:00:00 2001
+From: Christoph Paasch <christoph.paasch@uclouvain.be>
+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 <christoph.paasch@uclouvain.be>
+
+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] <IRQ> [<ffffffff81487847>] dump_stack+0x49/0x62
+[ 43.484174] [<ffffffff81034e7d>] warn_slowpath_common+0x77/0x91
+[ 43.556049] [<ffffffff813fff10>] ? dev_watchdog+0x15c/0x1fb
+[ 43.623759] [<ffffffff81034f2b>] warn_slowpath_fmt+0x41/0x43
+[ 43.692511] [<ffffffff813fff10>] dev_watchdog+0x15c/0x1fb
+[ 43.758141] [<ffffffff813ffdb4>] ? __netdev_watchdog_up+0x64/0x64
+[ 43.832091] [<ffffffff8103cd04>] call_timer_fn+0x17/0x6f
+[ 43.896682] [<ffffffff8103cebe>] run_timer_softirq+0x162/0x1a2
+[ 43.967511] [<ffffffff81038520>] __do_softirq+0xcd/0x1cc
+[ 44.032104] [<ffffffff81038689>] irq_exit+0x3a/0x48
+[ 44.091492] [<ffffffff81026d43>] smp_apic_timer_interrupt+0x43/0x50
+[ 44.167525] [<ffffffff8148c24a>] apic_timer_interrupt+0x6a/0x70
+[ 44.239392] <EOI> [<ffffffff8100992c>] ? default_idle+0x6/0x8
+[ 44.310343] [<ffffffff81009b31>] arch_cpu_idle+0x13/0x18
+[ 44.374934] [<ffffffff81066126>] cpu_startup_entry+0xa7/0x101
+[ 44.444724] [<ffffffff81025660>] 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] <IRQ> [<ffffffff81487847>] dump_stack+0x49/0x62
+[ 47.081585] [<ffffffff81068489>] __report_bad_irq+0x35/0xc1
+[ 47.149295] [<ffffffff81068683>] note_interrupt+0x16e/0x1ea
+[ 47.217006] [<ffffffff8106679e>] handle_irq_event_percpu+0x116/0x12e
+[ 47.294075] [<ffffffff810667e9>] handle_irq_event+0x33/0x4f
+[ 47.361787] [<ffffffff81068c95>] handle_fasteoi_irq+0x83/0xd1
+[ 47.431577] [<ffffffff81003d5b>] handle_irq+0x1f/0x28
+[ 47.493047] [<ffffffff81003567>] do_IRQ+0x4e/0xd4
+[ 47.550358] [<ffffffff8148b06a>] common_interrupt+0x6a/0x6a
+[ 47.618066] <EOI> [<ffffffff8100992c>] ? default_idle+0x6/0x8
+[ 47.689016] [<ffffffff81009b31>] arch_cpu_idle+0x13/0x18
+[ 47.753605] [<ffffffff81066126>] cpu_startup_entry+0xa7/0x101
+[ 47.823397] [<ffffffff81025660>] start_secondary+0x1b2/0x1b7
+[ 47.892146] handlers:
+[ 47.919301] [<ffffffff812fbd7d>] 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 <carolyn.wyborny@intel.com>
+Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
+Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 392369019eb96e914234ea21eda806cb51a1073e Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Sun, 6 Apr 2014 15:20:03 -0700
+Subject: leds: leds-pwm: properly clean up after probe failure
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+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 <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Bryan Wu <cooloney@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 3234f5b06fc3094176a86772cc64baf3decc98fc Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <ben@decadent.org.uk>
+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 <ben@decadent.org.uk>
+
+commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.
+
+Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
