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
This is a note to let you know that I've just added the patch titled
backlight: lcd: Fix race condition during register
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:
backlight-lcd-fix-race-condition-during-register.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: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Date: Wed, 6 Jul 2016 19:33:05 +0200
Subject: backlight: lcd: Fix race condition during register
From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
[ Upstream commit cc21942bce652d1a92dae85b785378256e1df1f7 ]
Once device_register is called for a device its attributes might be
accessed. As the callbacks of a lcd device's attributes make use of the
lcd_ops, the respective member must be setup before calling
device_register.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/backlight/lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/video/backlight/lcd.c
+++ b/drivers/video/backlight/lcd.c
@@ -226,6 +226,8 @@ struct lcd_device *lcd_device_register(c
dev_set_name(&new_ld->dev, "%s", name);
dev_set_drvdata(&new_ld->dev, devdata);
+ new_ld->ops = ops;
+
rc = device_register(&new_ld->dev);
if (rc) {
put_device(&new_ld->dev);
@@ -238,8 +240,6 @@ struct lcd_device *lcd_device_register(c
return ERR_PTR(rc);
}
- new_ld->ops = ops;
-
return new_ld;
}
EXPORT_SYMBOL(lcd_device_register);
Patches currently in stable-queue which might be from u.kleine-koenig(a)pengutronix.de are
queue-4.4/backlight-lcd-fix-race-condition-during-register.patch
This is a note to let you know that I've just added the patch titled
backlight: adp5520: Fix error handling in adp5520_bl_probe()
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:
backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.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: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 9 Jul 2016 01:19:51 +0300
Subject: backlight: adp5520: Fix error handling in adp5520_bl_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit 0eb3fba8c68275f0122f65f7316efaaf86448016 ]
If adp5520_bl_setup() fails, sysfs group left unremoved.
By the way, fix overcomplicated assignement of error code.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Acked-by: Michael Hennerich <michael.hennerich(a)analog.com>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/backlight/adp5520_bl.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -332,10 +332,18 @@ static int adp5520_bl_probe(struct platf
}
platform_set_drvdata(pdev, bl);
- ret |= adp5520_bl_setup(bl);
+ ret = adp5520_bl_setup(bl);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to setup\n");
+ if (data->pdata->en_ambl_sens)
+ sysfs_remove_group(&bl->dev.kobj,
+ &adp5520_bl_attr_group);
+ return ret;
+ }
+
backlight_update_status(bl);
- return ret;
+ return 0;
}
static int adp5520_bl_remove(struct platform_device *pdev)
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.4/backlight-adp5520-fix-error-handling-in-adp5520_bl_probe.patch
This is a note to let you know that I've just added the patch titled
ata: SATA_MV should depend on HAS_DMA
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:
ata-sata_mv-should-depend-on-has_dma.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: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Tue, 3 Jan 2017 19:09:44 +0100
Subject: ata: SATA_MV should depend on HAS_DMA
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 62989cebd367a1aae1e009e1a5b1ec046a4c8fdc ]
If NO_DMA=y:
ERROR: "dma_pool_alloc" [drivers/ata/sata_mv.ko] undefined!
ERROR: "dmam_pool_create" [drivers/ata/sata_mv.ko] undefined!
ERROR: "dma_pool_free" [drivers/ata/sata_mv.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -329,6 +329,7 @@ config SATA_HIGHBANK
config SATA_MV
tristate "Marvell SATA support"
+ depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.4/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.4/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.4/ata-ata_bmdma-should-depend-on-has_dma.patch
This is a note to let you know that I've just added the patch titled
ata: SATA_HIGHBANK should depend on HAS_DMA
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:
ata-sata_highbank-should-depend-on-has_dma.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: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Tue, 3 Jan 2017 19:09:45 +0100
Subject: ata: SATA_HIGHBANK should depend on HAS_DMA
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 2a736e0585e585c2566b5119af8381910a170e44 ]
If NO_DMA=y:
ERROR: "bad_dma_ops" [drivers/ata/sata_highbank.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -319,6 +319,7 @@ config SATA_DWC_VDEBUG
config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
+ depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
This option enables support for the Calxeda Highbank SoC's
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.4/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.4/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.4/ata-ata_bmdma-should-depend-on-has_dma.patch
This is a note to let you know that I've just added the patch titled
ata: ATA_BMDMA should depend on HAS_DMA
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:
ata-ata_bmdma-should-depend-on-has_dma.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: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Tue, 3 Jan 2017 19:09:46 +0100
Subject: ata: ATA_BMDMA should depend on HAS_DMA
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 7bc7ab1e63dfe004931502f90ce7020e375623da ]
If NO_DMA=y:
ERROR: "dmam_alloc_coherent" [drivers/ata/libata.ko] undefined!
Add a dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -272,6 +272,7 @@ config SATA_SX4
config ATA_BMDMA
bool "ATA BMDMA support"
+ depends on HAS_DMA
default y
help
This option adds support for SFF ATA controllers with BMDMA
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.4/ata-sata_mv-should-depend-on-has_dma.patch
queue-4.4/ata-sata_highbank-should-depend-on-has_dma.patch
queue-4.4/ata-ata_bmdma-should-depend-on-has_dma.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: NS2: reserve memory for Nitro firmware
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:
arm64-dts-ns2-reserve-memory-for-nitro-firmware.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: Jon Mason <jon.mason(a)broadcom.com>
Date: Mon, 5 Dec 2016 18:12:21 -0500
Subject: arm64: dts: NS2: reserve memory for Nitro firmware
From: Jon Mason <jon.mason(a)broadcom.com>
[ Upstream commit 0cc878d678444392ca2a31350f89f489593ef5bb ]
Nitro firmware is loaded into memory by the bootloader at a specific
location. Set this memory range aside to prevent the kernel from using
it.
Signed-off-by: Jon Mason <jon.mason(a)broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -30,6 +30,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+/memreserve/ 0x81000000 0x00200000;
+
#include <dt-bindings/interrupt-controller/arm-gic.h>
/memreserve/ 0x84b00000 0x00000008;
Patches currently in stable-queue which might be from jon.mason(a)broadcom.com are
queue-4.4/arm64-dts-ns2-reserve-memory-for-nitro-firmware.patch
This is a note to let you know that I've just added the patch titled
ARM: OMAP2+: Fix init for multiple quirks for the same SoC
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:
arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.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: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:08:20 -0800
Subject: ARM: OMAP2+: Fix init for multiple quirks for the same SoC
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 6e613ebf4405fc09e2a8c16ed193b47f80a3cbed ]
It's possible that there are multiple quirks that need to be initialized
for the same SoC. Fix the issue by not returning on the first match.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-omap2/pdata-quirks.c | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -522,7 +522,6 @@ static void pdata_quirks_check(struct pd
if (of_machine_is_compatible(quirks->compatible)) {
if (quirks->fn)
quirks->fn();
- break;
}
quirks++;
}
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.4/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.4/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.4/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.4/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix omap3 off mode pull defines
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:
arm-dts-fix-omap3-off-mode-pull-defines.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: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:07:18 -0800
Subject: ARM: dts: Fix omap3 off mode pull defines
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit d97556c8012015901a3ce77f46960078139cd79d ]
We need to also have OFFPULLUDENABLE bit set to use the off mode pull values.
Otherwise the line is pulled down internally if no external pull exists.
This is has some documentation at:
http://processors.wiki.ti.com/index.php/Optimizing_OMAP35x_and_AM/DM37x_OFF…
Note that the value is still glitchy during off mode transitions as documented
in spz319f.pdf "Advisory 1.45". It's best to use external pulls instead of
relying on the internal ones for off mode and even then anything pulled up
will get driven down momentarily on off mode restore for GPIO banks other
than bank1.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/dt-bindings/pinctrl/omap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -45,8 +45,8 @@
#define PIN_OFF_NONE 0
#define PIN_OFF_OUTPUT_HIGH (OFF_EN | OFFOUT_EN | OFFOUT_VAL)
#define PIN_OFF_OUTPUT_LOW (OFF_EN | OFFOUT_EN)
-#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFF_PULL_EN | OFF_PULL_UP)
-#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN)
+#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFFOUT_EN | OFF_PULL_EN | OFF_PULL_UP)
+#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFFOUT_EN | OFF_PULL_EN)
#define PIN_OFF_WAKEUPENABLE WAKEUP_EN
/*
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.4/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.4/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.4/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.4/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix compatible for ti81xx uarts for 8250
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:
arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.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: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:17:30 -0800
Subject: ARM: dts: Fix compatible for ti81xx uarts for 8250
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit f62280efe8934a1275fd148ef302d1afec8cd3df ]
When using 8250_omap driver, we need to specify the right
compatible value for the UART to work on dm814x and dm816x.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/dm814x.dtsi | 6 +++---
arch/arm/boot/dts/dm816x.dtsi | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -138,7 +138,7 @@
};
uart1: uart@20000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
reg = <0x20000 0x2000>;
clock-frequency = <48000000>;
@@ -148,7 +148,7 @@
};
uart2: uart@22000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart2";
reg = <0x22000 0x2000>;
clock-frequency = <48000000>;
@@ -158,7 +158,7 @@
};
uart3: uart@24000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart3";
reg = <0x24000 0x2000>;
clock-frequency = <48000000>;
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -347,7 +347,7 @@
};
uart1: uart@48020000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart1";
reg = <0x48020000 0x2000>;
clock-frequency = <48000000>;
@@ -357,7 +357,7 @@
};
uart2: uart@48022000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart2";
reg = <0x48022000 0x2000>;
clock-frequency = <48000000>;
@@ -367,7 +367,7 @@
};
uart3: uart@48024000 {
- compatible = "ti,omap3-uart";
+ compatible = "ti,am3352-uart", "ti,omap3-uart";
ti,hwmods = "uart3";
reg = <0x48024000 0x2000>;
clock-frequency = <48000000>;
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.4/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.4/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.4/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.4/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix am335x and dm814x scm syscon to probe children
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:
arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.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: Tony Lindgren <tony(a)atomide.com>
Date: Thu, 5 Jan 2017 11:10:40 -0800
Subject: ARM: dts: Fix am335x and dm814x scm syscon to probe children
From: Tony Lindgren <tony(a)atomide.com>
[ Upstream commit 1aa09df0854efe16b7a80358a18f0a0bebafd246 ]
Without these changes children of the scn syscon
won't probe.
Signed-off-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/am33xx.dtsi | 3 ++-
arch/arm/boot/dts/dm814x.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -142,10 +142,11 @@
};
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x800>;
scm_clocks: clocks {
#address-cells = <1>;
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -189,10 +189,11 @@
ranges = <0 0x160000 0x16d000>;
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <0 0 0x800>;
scm_clocks: clocks {
#address-cells = <1>;
Patches currently in stable-queue which might be from tony(a)atomide.com are
queue-4.4/arm-dts-fix-omap3-off-mode-pull-defines.patch
queue-4.4/arm-dts-fix-compatible-for-ti81xx-uarts-for-8250.patch
queue-4.4/arm-omap2-fix-init-for-multiple-quirks-for-the-same-soc.patch
queue-4.4/arm-dts-fix-am335x-and-dm814x-scm-syscon-to-probe-children.patch
Hi,
I'd like the following patch to be applied to stable for versions
between 4.1 and 4.10 (inclusively).
This is a minimal fix for a bug where arm32 kernels can use a much
slower implementation of AES than is actually available, potentially
forcing vendors to disable encryption on their devices.
Min version is 4.1 because that was the first version to include the
aes-ce algorithms.
Max version is 4.10 because in 4.11, this bug was fixed incidentally as
part of a complete rewrite of the bit-sliced AES implementation.
---8<---
All the aes-bs (bit-sliced) and aes-ce (cryptographic extensions)
algorithms had a priority of 300. This is undesirable because it means
an aes-bs algorithm may be used when an aes-ce algorithm is available.
The aes-ce algorithms have much better performance (up to 10x faster).
Fix it by decreasing the priority of the aes-bs algorithms to 250.
This was fixed upstream by commit cc477bf64573 ("crypto: arm/aes -
replace bit-sliced OpenSSL NEON code"), but it was just a small part of
a complete rewrite. This patch just fixes the priority bug for older
kernels.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
arch/arm/crypto/aesbs-glue.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/aesbs-glue.c b/arch/arm/crypto/aesbs-glue.c
index 0511a6cafe24..5d934a0039d7 100644
--- a/arch/arm/crypto/aesbs-glue.c
+++ b/arch/arm/crypto/aesbs-glue.c
@@ -363,7 +363,7 @@ static struct crypto_alg aesbs_algs[] = { {
}, {
.cra_name = "cbc(aes)",
.cra_driver_name = "cbc-aes-neonbs",
- .cra_priority = 300,
+ .cra_priority = 250,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER|CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct async_helper_ctx),
@@ -383,7 +383,7 @@ static struct crypto_alg aesbs_algs[] = { {
}, {
.cra_name = "ctr(aes)",
.cra_driver_name = "ctr-aes-neonbs",
- .cra_priority = 300,
+ .cra_priority = 250,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER|CRYPTO_ALG_ASYNC,
.cra_blocksize = 1,
.cra_ctxsize = sizeof(struct async_helper_ctx),
@@ -403,7 +403,7 @@ static struct crypto_alg aesbs_algs[] = { {
}, {
.cra_name = "xts(aes)",
.cra_driver_name = "xts-aes-neonbs",
- .cra_priority = 300,
+ .cra_priority = 250,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER|CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct async_helper_ctx),
--
2.15.0.448.gf294e3d99a-goog
This is a note to let you know that I've just added the patch titled
ALSA: vx: Don't try to update capture stream before running
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:
alsa-vx-don-t-try-to-update-capture-stream-before-running.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: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 4 Jan 2017 12:34:14 +0100
Subject: ALSA: vx: Don't try to update capture stream before running
From: Takashi Iwai <tiwai(a)suse.de>
[ Upstream commit ed3c177d960bb5881b945ca6f784868126bb90db ]
The update of stream costs significantly, and we should avoid it
unless the stream really has started. Check pipe->running flag
instead of pipe->prepared.
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/drivers/vx/vx_pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/drivers/vx/vx_pcm.c
+++ b/sound/drivers/vx/vx_pcm.c
@@ -1015,7 +1015,7 @@ static void vx_pcm_capture_update(struct
int size, space, count;
struct snd_pcm_runtime *runtime = subs->runtime;
- if (! pipe->prepared || (chip->chip_status & VX_STAT_IS_STALE))
+ if (!pipe->running || (chip->chip_status & VX_STAT_IS_STALE))
return;
size = runtime->buffer_size - snd_pcm_capture_avail(runtime);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.4/alsa-vx-don-t-try-to-update-capture-stream-before-running.patch
queue-4.4/alsa-vx-fix-possible-transfer-overflow.patch
queue-4.4/alsa-hda-realtek-add-new-codec-id-alc299.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda/realtek - Add new codec ID ALC299
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:
alsa-hda-realtek-add-new-codec-id-alc299.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: Kailang Yang <kailang(a)realtek.com>
Date: Wed, 4 Jan 2017 14:49:07 +0800
Subject: ALSA: hda/realtek - Add new codec ID ALC299
From: Kailang Yang <kailang(a)realtek.com>
[ Upstream commit 28f1f9b26cee161ddd3985b3eb78e3ffada08dda ]
ALC299 was similar as ALC225.
Add headset support for ALC299.
ALC3271 was for Dell rename.
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -338,6 +338,7 @@ static void alc_fill_eapd_coef(struct hd
case 0x10ec0288:
case 0x10ec0295:
case 0x10ec0298:
+ case 0x10ec0299:
alc_update_coef_idx(codec, 0x10, 1<<9, 0);
break;
case 0x10ec0285:
@@ -914,6 +915,7 @@ static struct alc_codec_rename_pci_table
{ 0x10ec0256, 0x1028, 0, "ALC3246" },
{ 0x10ec0225, 0x1028, 0, "ALC3253" },
{ 0x10ec0295, 0x1028, 0, "ALC3254" },
+ { 0x10ec0299, 0x1028, 0, "ALC3271" },
{ 0x10ec0670, 0x1025, 0, "ALC669X" },
{ 0x10ec0676, 0x1025, 0, "ALC679X" },
{ 0x10ec0282, 0x1043, 0, "ALC3229" },
@@ -3721,6 +3723,7 @@ static void alc_headset_mode_unplugged(s
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
}
@@ -3823,6 +3826,7 @@ static void alc_headset_mode_mic_in(stru
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_update_coef_idx(codec, 0x45, 0x3f<<10, 0x31<<10);
snd_hda_set_pin_ctl_cache(codec, hp_pin, 0);
alc_process_coef_fw(codec, coef0225);
@@ -3881,6 +3885,7 @@ static void alc_headset_mode_default(str
switch (codec->core.vendor_id) {
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
case 0x10ec0236:
@@ -3995,6 +4000,7 @@ static void alc_headset_mode_ctia(struct
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
}
@@ -4086,6 +4092,7 @@ static void alc_headset_mode_omtp(struct
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
break;
}
@@ -4171,6 +4178,7 @@ static void alc_determine_headset_type(s
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
alc_process_coef_fw(codec, coef0225);
msleep(800);
val = alc_read_coef_idx(codec, 0x46);
@@ -6233,6 +6241,7 @@ static int patch_alc269(struct hda_codec
break;
case 0x10ec0225:
case 0x10ec0295:
+ case 0x10ec0299:
spec->codec_variant = ALC269_TYPE_ALC225;
break;
case 0x10ec0234:
@@ -7191,6 +7200,7 @@ static const struct hda_device_id snd_hd
HDA_CODEC_ENTRY(0x10ec0294, "ALC294", patch_alc269),
HDA_CODEC_ENTRY(0x10ec0295, "ALC295", patch_alc269),
HDA_CODEC_ENTRY(0x10ec0298, "ALC298", patch_alc269),
+ HDA_CODEC_ENTRY(0x10ec0299, "ALC299", patch_alc269),
HDA_CODEC_REV_ENTRY(0x10ec0861, 0x100340, "ALC660", patch_alc861),
HDA_CODEC_ENTRY(0x10ec0660, "ALC660-VD", patch_alc861vd),
HDA_CODEC_ENTRY(0x10ec0861, "ALC861", patch_alc861),
Patches currently in stable-queue which might be from kailang(a)realtek.com are
queue-4.4/alsa-hda-realtek-add-new-codec-id-alc299.patch