This is a note to let you know that I've just added the patch titled
igb: reset the PHY before reading the PHY ID
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-reset-the-phy-before-reading-the-phy-id.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Aaron Sierra <asierra(a)xes-inc.com>
Date: Tue, 29 Nov 2016 10:03:56 -0600
Subject: igb: reset the PHY before reading the PHY ID
From: Aaron Sierra <asierra(a)xes-inc.com>
[ Upstream commit 182785335447957409282ca745aa5bc3968facee ]
Several people have reported firmware leaving the I210/I211 PHY's page
select register set to something other than the default of zero. This
causes the first accesses, PHY_IDx register reads, to access something
else, resulting in device probe failure:
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
igb: Copyright (c) 2007-2014 Intel Corporation.
igb: probe of 0000:01:00.0 failed with error -2
This problem began for them after a previous patch I submitted was
applied:
commit 2a3cdead8b408351fa1e3079b220fa331480ffbc
Author: Aaron Sierra <asierra(a)xes-inc.com>
Date: Tue Nov 3 12:37:09 2015 -0600
igb: Remove GS40G specific defines/functions
I personally experienced this problem after attempting to PXE boot from
I210 devices using this firmware:
Intel(R) Boot Agent GE v1.5.78
Copyright (C) 1997-2014, Intel Corporation
Resetting the PHY before reading from it, ensures the page select
register is in its default state and doesn't make assumptions about
the PHY's register set before the PHY has been probed.
Cc: Matwey V. Kornilov <matwey(a)sai.msu.ru>
Cc: Chris Arges <carges(a)vectranetworks.com>
Cc: Jochen Henneberg <jh(a)henneberg-systemdesign.com>
Signed-off-by: Aaron Sierra <asierra(a)xes-inc.com>
Tested-by: Matwey V. Kornilov <matwey(a)sai.msu.ru>
Tested-by: Chris J Arges <christopherarges(a)gmail.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -223,6 +223,17 @@ static s32 igb_init_phy_params_82575(str
hw->bus.func = (rd32(E1000_STATUS) & E1000_STATUS_FUNC_MASK) >>
E1000_STATUS_FUNC_SHIFT;
+ /* Make sure the PHY is in a good state. Several people have reported
+ * firmware leaving the PHY's page select register set to something
+ * other than the default of zero, which causes the PHY ID read to
+ * access something other than the intended register.
+ */
+ ret_val = hw->phy.ops.reset(hw);
+ if (ret_val) {
+ hw_dbg("Error resetting the PHY.\n");
+ goto out;
+ }
+
/* Set phy->phy_addr and phy->id. */
ret_val = igb_get_phy_id_82575(hw);
if (ret_val)
Patches currently in stable-queue which might be from asierra(a)xes-inc.com are
queue-4.4/igb-reset-the-phy-before-reading-the-phy-id.patch
This is a note to let you know that I've just added the patch titled
igb: Fix hw_dbg logging in igb_update_flash_i210
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Hannu Lounento <hannu.lounento(a)ge.com>
Date: Mon, 2 Jan 2017 18:26:06 +0100
Subject: igb: Fix hw_dbg logging in igb_update_flash_i210
From: Hannu Lounento <hannu.lounento(a)ge.com>
[ Upstream commit 76ed5a8f47476e4984cc8c0c1bc4cee62650f7fd ]
Fix an if statement with hw_dbg lines where the logic was inverted with
regards to the corresponding return value used in the if statement.
Signed-off-by: Hannu Lounento <hannu.lounento(a)ge.com>
Signed-off-by: Peter Senna Tschudin <peter.senna(a)collabora.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/e1000_i210.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/intel/igb/e1000_i210.c
+++ b/drivers/net/ethernet/intel/igb/e1000_i210.c
@@ -699,9 +699,9 @@ static s32 igb_update_flash_i210(struct
ret_val = igb_pool_flash_update_done_i210(hw);
if (ret_val)
- hw_dbg("Flash update complete\n");
- else
hw_dbg("Flash update time out\n");
+ else
+ hw_dbg("Flash update complete\n");
out:
return ret_val;
Patches currently in stable-queue which might be from hannu.lounento(a)ge.com are
queue-4.4/igb-fix-hw_dbg-logging-in-igb_update_flash_i210.patch
This is a note to let you know that I've just added the patch titled
igb: close/suspend race in netif_device_detach
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
igb-close-suspend-race-in-netif_device_detach.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Todd Fujinaka <todd.fujinaka(a)intel.com>
Date: Tue, 15 Nov 2016 08:54:26 -0800
Subject: igb: close/suspend race in netif_device_detach
From: Todd Fujinaka <todd.fujinaka(a)intel.com>
[ Upstream commit 9474933caf21a4cb5147223dca1551f527aaac36 ]
Similar to ixgbe, when an interface is part of a namespace it is
possible that igb_close() may be called while __igb_shutdown() is
running which ends up in a double free WARN and/or a BUG in
free_msi_irqs().
Extend the rtnl_lock() to protect the call to netif_device_detach() and
igb_clear_interrupt_scheme() in __igb_shutdown() and check for
netif_device_present() to avoid calling igb_clear_interrupt_scheme() a
second time in igb_close().
Also extend the rtnl lock in igb_resume() to netif_device_attach().
Signed-off-by: Todd Fujinaka <todd.fujinaka(a)intel.com>
Acked-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3172,7 +3172,9 @@ static int __igb_close(struct net_device
static int igb_close(struct net_device *netdev)
{
- return __igb_close(netdev, false);
+ if (netif_device_present(netdev))
+ return __igb_close(netdev, false);
+ return 0;
}
/**
@@ -7325,12 +7327,14 @@ static int __igb_shutdown(struct pci_dev
int retval = 0;
#endif
+ rtnl_lock();
netif_device_detach(netdev);
if (netif_running(netdev))
__igb_close(netdev, true);
igb_clear_interrupt_scheme(adapter);
+ rtnl_unlock();
#ifdef CONFIG_PM
retval = pci_save_state(pdev);
@@ -7450,16 +7454,15 @@ static int igb_resume(struct device *dev
wr32(E1000_WUS, ~0);
- if (netdev->flags & IFF_UP) {
- rtnl_lock();
+ rtnl_lock();
+ if (!err && netif_running(netdev))
err = __igb_open(netdev, true);
- rtnl_unlock();
- if (err)
- return err;
- }
- netif_device_attach(netdev);
- return 0;
+ if (!err)
+ netif_device_attach(netdev);
+ rtnl_unlock();
+
+ return err;
}
static int igb_runtime_idle(struct device *dev)
Patches currently in stable-queue which might be from todd.fujinaka(a)intel.com are
queue-4.4/igb-close-suspend-race-in-netif_device_detach.patch
This is a note to let you know that I've just added the patch titled
gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Tue, 3 Jan 2017 17:00:27 +0530
Subject: gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 4b0ea93f250afc6c1128e201b0a8a115ae613e47 ]
Here, pci_iomap can fail, handle this case and return -ENOMEM.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1483443027-13444-1-git-send-em…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/mgag200/mgag200_main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -145,6 +145,8 @@ static int mga_vram_init(struct mga_devi
}
mem = pci_iomap(mdev->dev->pdev, 0, 0);
+ if (!mem)
+ return -ENOMEM;
mdev->mc.vram_size = mga_probe_vram(mdev, mem);
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.4/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.4/media-imon-fix-null-ptr-deref-in-imon_probe.patch
queue-4.4/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
This is a note to let you know that I've just added the patch titled
fm10k: request reset when mbx->state changes
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fm10k-request-reset-when-mbx-state-changes.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com>
Date: Wed, 2 Nov 2016 16:44:46 -0700
Subject: fm10k: request reset when mbx->state changes
From: Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com>
[ Upstream commit 2f3fc1e6200309ccf87f61dea56e57e563c4f800 ]
Multiple IES API resets can cause a race condition where the mailbox
interrupt request bits can be cleared before being handled. This can
leave certain mailbox messages from the PF to be untreated and the PF
will enter in some inactive state. If this situation occurs, the IES API
will initiate a mailbox version reset which, then, trigger a mailbox
state change. Once this mailbox transition occurs (from OPEN to CONNECT
state), a request for reset will be returned.
This ensures that PF will undergo a reset whenever IES API encounters an
unknown global mailbox interrupt event or whenever the IES API
terminates.
Signed-off-by: Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller(a)intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 10 +++++++---
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 +++++-
2 files changed, 12 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_mbx.c
@@ -2002,9 +2002,10 @@ static void fm10k_sm_mbx_create_reply(st
* function can also be used to respond to an error as the connection
* resetting would also be a means of dealing with errors.
**/
-static void fm10k_sm_mbx_process_reset(struct fm10k_hw *hw,
- struct fm10k_mbx_info *mbx)
+static s32 fm10k_sm_mbx_process_reset(struct fm10k_hw *hw,
+ struct fm10k_mbx_info *mbx)
{
+ s32 err = 0;
const enum fm10k_mbx_state state = mbx->state;
switch (state) {
@@ -2017,6 +2018,7 @@ static void fm10k_sm_mbx_process_reset(s
case FM10K_STATE_OPEN:
/* flush any incomplete work */
fm10k_sm_mbx_connect_reset(mbx);
+ err = FM10K_ERR_RESET_REQUESTED;
break;
case FM10K_STATE_CONNECT:
/* Update remote value to match local value */
@@ -2026,6 +2028,8 @@ static void fm10k_sm_mbx_process_reset(s
}
fm10k_sm_mbx_create_reply(hw, mbx, mbx->tail);
+
+ return err;
}
/**
@@ -2106,7 +2110,7 @@ static s32 fm10k_sm_mbx_process(struct f
switch (FM10K_MSG_HDR_FIELD_GET(mbx->mbx_hdr, SM_VER)) {
case 0:
- fm10k_sm_mbx_process_reset(hw, mbx);
+ err = fm10k_sm_mbx_process_reset(hw, mbx);
break;
case FM10K_SM_MBX_VERSION:
err = fm10k_sm_mbx_process_version_1(hw, mbx);
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -1072,6 +1072,7 @@ static irqreturn_t fm10k_msix_mbx_pf(int
struct fm10k_hw *hw = &interface->hw;
struct fm10k_mbx_info *mbx = &hw->mbx;
u32 eicr;
+ s32 err = 0;
/* unmask any set bits related to this interrupt */
eicr = fm10k_read_reg(hw, FM10K_EICR);
@@ -1087,12 +1088,15 @@ static irqreturn_t fm10k_msix_mbx_pf(int
/* service mailboxes */
if (fm10k_mbx_trylock(interface)) {
- mbx->ops.process(hw, mbx);
+ err = mbx->ops.process(hw, mbx);
/* handle VFLRE events */
fm10k_iov_event(interface);
fm10k_mbx_unlock(interface);
}
+ if (err == FM10K_ERR_RESET_REQUESTED)
+ interface->flags |= FM10K_FLAG_RESET_REQUESTED;
+
/* if switch toggled state we should reset GLORTs */
if (eicr & FM10K_EICR_SWITCHNOTREADY) {
/* force link down for at least 4 seconds */
Patches currently in stable-queue which might be from ngai-mint.kwan(a)intel.com are
queue-4.4/fm10k-request-reset-when-mbx-state-changes.patch
This is a note to let you know that I've just added the patch titled
extcon: palmas: Check the parent instance to prevent the NULL
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Roger Quadros <rogerq(a)ti.com>
Date: Thu, 8 Dec 2016 10:45:31 +0200
Subject: extcon: palmas: Check the parent instance to prevent the NULL
From: Roger Quadros <rogerq(a)ti.com>
[ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ]
extcon-palmas must be child of palmas and expects parent's
drvdata to be valid. Check for non NULL parent drvdata and
fail if it is NULL. Not doing so will result in a NULL
pointer dereference later in the probe() parent drvdata
is NULL (e.g. misplaced extcon-palmas node in device tree).
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/extcon/extcon-palmas.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -190,6 +190,11 @@ static int palmas_usb_probe(struct platf
struct palmas_usb *palmas_usb;
int status;
+ if (!palmas) {
+ dev_err(&pdev->dev, "failed to get valid parent\n");
+ return -EINVAL;
+ }
+
palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL);
if (!palmas_usb)
return -ENOMEM;
Patches currently in stable-queue which might be from rogerq(a)ti.com are
queue-4.4/extcon-palmas-check-the-parent-instance-to-prevent-the-null.patch
This is a note to let you know that I've just added the patch titled
drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Nov 19 12:02:55 CET 2017
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Wed, 21 Dec 2016 11:00:12 +0530
Subject: drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 1ae0d5af347df224a6e76334683f13a96d915a44 ]
Here, If devm_ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference. This error check
will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Acked-by: Vincent Abriou <vincent.abriou(a)st.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sti/sti_vtg.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -346,6 +346,10 @@ static int vtg_probe(struct platform_dev
return -ENOMEM;
}
vtg->regs = devm_ioremap_nocache(dev, res->start, resource_size(res));
+ if (!vtg->regs) {
+ DRM_ERROR("failed to remap I/O memory\n");
+ return -ENOMEM;
+ }
np = of_parse_phandle(pdev->dev.of_node, "st,slave", 0);
if (np) {
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.4/gpu-drm-mgag200-mgag200_main-handle-error-from-pci_iomap.patch
queue-4.4/media-imon-fix-null-ptr-deref-in-imon_probe.patch
queue-4.4/drm-sti-sti_vtg-handle-return-null-error-from-devm_ioremap_nocache.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: warn user when dma test times out
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Thu, 2 Nov 2017 08:53:30 -0400
Subject: dmaengine: dmatest: warn user when dma test times out
From: Adam Wallis <awallis(a)codeaurora.org>
commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -634,6 +634,7 @@ static int dmatest_func(void *data)
* free it this time?" dancing. For now, just
* leave it dangling.
*/
+ WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.4/dmaengine-dmatest-warn-user-when-dma-test-times-out.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: fix QCA Rome suspend/resume
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btusb-fix-qca-rome-suspend-resume.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fd865802c66bc451dc515ed89360f84376ce1a56 Mon Sep 17 00:00:00 2001
From: Leif Liddy <leif.linux(a)gmail.com>
Date: Sat, 8 Jul 2017 20:55:32 +0200
Subject: Bluetooth: btusb: fix QCA Rome suspend/resume
From: Leif Liddy <leif.linux(a)gmail.com>
commit fd865802c66bc451dc515ed89360f84376ce1a56 upstream.
There's been numerous reported instances where BTUSB_QCA_ROME
bluetooth controllers stop functioning upon resume from suspend. These
devices seem to be losing power during suspend. Patch will detect a status
change on resume and perform a reset.
Signed-off-by: Leif Liddy <leif.linux(a)gmail.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Cc: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2969,6 +2969,12 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
+
+ /* QCA Rome devices lose their updated firmware over suspend,
+ * but the USB hub doesn't notice any status change.
+ * Explicitly request a device reset on resume.
+ */
+ set_bit(BTUSB_RESET_RESUME, &data->flags);
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
Patches currently in stable-queue which might be from leif.linux(a)gmail.com are
queue-4.4/bluetooth-btusb-fix-qca-rome-suspend-resume.patch