This is a note to let you know that I've just added the patch titled
usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
to the 4.14-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:
usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:49 -0700
Subject: usb: dwc2: Error out of dwc2_hsotg_ep_disable() if we're in host mode
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit 9b481092c2a31a6b630aff9c28f0145bf6683787 ]
We've found that while in host mode, using Android, if one runs
the command:
stop adbd
The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.
This seems to be due to adbd closing the file:
/dev/usb-ffs/adb/ep0
Which calls ffs_ep0_release() and the following backtrace:
[<ffffff800875a430>] dwc2_hsotg_ep_disable+0x148/0x150
[<ffffff800875a498>] dwc2_hsotg_udc_stop+0x60/0x110
[<ffffff8008787950>] usb_gadget_remove_driver+0x58/0x78
[<ffffff80087879e4>] usb_gadget_unregister_driver+0x74/0xe8
[<ffffff80087850c0>] unregister_gadget+0x28/0x58
[<ffffff800878511c>] unregister_gadget_item+0x2c/0x40
[<ffffff8008790ea8>] ffs_data_clear+0xe8/0xf8
[<ffffff8008790ed8>] ffs_data_reset+0x20/0x58
[<ffffff8008793218>] ffs_data_closed+0x98/0xe8
[<ffffff80087932d8>] ffs_ep0_release+0x20/0x30
Then when dwc2_hsotg_ep_disable() is called, we call
kill_all_requests() which causes a bunch of the following
messages:
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c0000.usb: Mode Mismatch Interrupt: currently in Host mode
init: Service 'adbd' (pid 1915) killed by signal 9
init: Sending signal 9 to service 'adbd' (pid 1915) process group...
init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:15)
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
dwc2 f72c0000.usb: hcint 0x00000002, intsts 0x04200029
dwc2 f72c0000.usb: dwc2_update_urb_state_abn(): trimming xfer length
And the usb devices connected are basically hung at this point.
It seems like if we're in host mode, we probably shouldn't run
the dwc2_hostg_ep_disable logic, so this patch returns an error
in that case.
With this patch (along with the previous patch in this set), we avoid
the mismatched interrupts and connected usb devices continue to function.
I'm not sure if some other solution would be better here, but this seems
to work, so I wanted to send it out for input on what the right approach
should be.
Cc: Wei Xu <xuwei5(a)hisilicon.com>
Cc: Guodong Xu <guodong.xu(a)linaro.org>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: John Youn <johnyoun(a)synopsys.com>
Cc: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Cc: Douglas Anderson <dianders(a)chromium.org>
Cc: Chen Yu <chenyu56(a)huawei.com>
Cc: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: linux-usb(a)vger.kernel.org
Acked-by: Minas Harutyunyan <hminas(a)synopsys.com>
Tested-by: Minas Harutyunyan <hminas(a)synopsys.com>
Reported-by: YongQin Liu <yongqin.liu(a)linaro.org>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc2/gadget.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -4006,6 +4006,11 @@ static int dwc2_hsotg_ep_disable(struct
return -EINVAL;
}
+ if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+ dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
+ return -EINVAL;
+ }
+
epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
spin_lock_irqsave(&hsotg->lock, flags);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.14/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.14/usb-dwc2-fix-udc-state-tracking.patch
This is a note to let you know that I've just added the patch titled
tools include: Do not use poison with C++
to the 4.14-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:
tools-include-do-not-use-poison-with-c.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Date: Thu, 21 Sep 2017 12:12:17 -0300
Subject: tools include: Do not use poison with C++
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[ Upstream commit 6ae8eefc6c8fe050f057781b70a83262eb0a61ee ]
LIST_POISON[12] are used to initialize list_head and hlist_node
pointers, and do void pointer arithmetic, which C++ doesn't like, so, to
avoid drifting from the kernel by introducing some HLIST_POISON to do
away with void pointer math, just make those poisoned pointers be NULL
when building it with a C++ compiler.
Noticed with:
$ make LLVM_CONFIG=/usr/bin/llvm-config-3.9 LIBCLANGLLVM=1
CXX util/c++/clang.o
CXX util/c++/clang-test.o
In file included from /home/lizj/linux/tools/include/linux/list.h:5:0,
from /home/lizj/linux/tools/perf/util/namespaces.h:13,
from /home/lizj/linux/tools/perf/util/util.h:15,
from /home/lizj/linux/tools/perf/util/util-cxx.h:20,
from util/c++/clang-c.h:5,
from util/c++/clang-test.cpp:2:
/home/lizj/linux/tools/include/linux/list.h: In function ‘void list_del(list_head*)’:
/home/lizj/linux/tools/include/linux/poison.h:14:31: error: pointer of type ‘void *’ used in arithmetic [-Werror=pointer-arith]
# define POISON_POINTER_DELTA 0
^
/home/lizj/linux/tools/include/linux/poison.h:22:41: note: in expansion of macro ‘POISON_POINTER_DELTA’
#define LIST_POISON1 ((void *) 0x100 + POISON_POINTER_DELTA)
^
/home/lizj/linux/tools/include/linux/list.h:107:16: note: in expansion of macro ‘LIST_POISON1’
entry->next = LIST_POISON1;
^
In file included from /home/lizj/linux/tools/perf/util/namespaces.h:13:0,
from /home/lizj/linux/tools/perf/util/util.h:15,
from /home/lizj/linux/tools/perf/util/util-cxx.h:20,
from util/c++/clang-c.h:5,
from util/c++/clang-test.cpp:2:
/home/lizj/linux/tools/include/linux/list.h:107:14: error: invalid conversion from ‘void*’ to ‘list_head*’ [-fpermissive]
Reported-by: Li Zhijian <lizhijian(a)cn.fujitsu.com>
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Philip Li <philip.li(a)intel.com>
Cc: Wang Nan <wangnan0(a)huawei.com>
Link: http://lkml.kernel.org/n/tip-m5ei2o0mjshucbr28baf5lqz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/include/linux/poison.h | 5 +++++
1 file changed, 5 insertions(+)
--- a/tools/include/linux/poison.h
+++ b/tools/include/linux/poison.h
@@ -15,6 +15,10 @@
# define POISON_POINTER_DELTA 0
#endif
+#ifdef __cplusplus
+#define LIST_POISON1 NULL
+#define LIST_POISON2 NULL
+#else
/*
* These are non-NULL pointers that will result in page faults
* under normal circumstances, used to verify that nobody uses
@@ -22,6 +26,7 @@
*/
#define LIST_POISON1 ((void *) 0x100 + POISON_POINTER_DELTA)
#define LIST_POISON2 ((void *) 0x200 + POISON_POINTER_DELTA)
+#endif
/********** include/linux/timer.h **********/
/*
Patches currently in stable-queue which might be from acme(a)redhat.com are
queue-4.14/perf-tools-fix-leaking-rec_argv-in-error-cases.patch
queue-4.14/perf-test-attr-fix-ignored-test-case-result.patch
queue-4.14/perf-test-attr-fix-python-error-on-empty-result.patch
queue-4.14/tools-include-do-not-use-poison-with-c.patch
This is a note to let you know that I've just added the patch titled
sysrq : fix Show Regs call trace on ARM
to the 4.14-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:
sysrq-fix-show-regs-call-trace-on-arm.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Jibin Xu <jibin.xu(a)windriver.com>
Date: Sun, 10 Sep 2017 20:11:42 -0700
Subject: sysrq : fix Show Regs call trace on ARM
From: Jibin Xu <jibin.xu(a)windriver.com>
[ Upstream commit b00bebbc301c8e1f74f230dc82282e56b7e7a6db ]
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [00000000] code: sh/435
caller is __this_cpu_preempt_check+0x18/0x20
Call trace:
[<ffffff8008088e80>] dump_backtrace+0x0/0x1d0
[<ffffff8008089074>] show_stack+0x24/0x30
[<ffffff8008447970>] dump_stack+0x90/0xb0
[<ffffff8008463950>] check_preemption_disabled+0x100/0x108
[<ffffff8008463998>] __this_cpu_preempt_check+0x18/0x20
[<ffffff80084c9194>] sysrq_handle_showregs+0x1c/0x40
[<ffffff80084c9c7c>] __handle_sysrq+0x12c/0x1a0
[<ffffff80084ca140>] write_sysrq_trigger+0x60/0x70
[<ffffff8008251e00>] proc_reg_write+0x90/0xd0
[<ffffff80081f1788>] __vfs_write+0x48/0x90
[<ffffff80081f241c>] vfs_write+0xa4/0x190
[<ffffff80081f3354>] SyS_write+0x54/0xb0
[<ffffff80080833f0>] el0_svc_naked+0x24/0x28
This can be seen on a common board like an r-pi3.
This happens because when echo p >/proc/sysrq-trigger,
get_irq_regs() is called outside of IRQ context,
if preemption is enabled in this situation,kernel will
print the call trace. Since many prior discussions on
the mailing lists have made it clear that get_irq_regs
either just returns NULL or stale data when used outside
of IRQ context,we simply avoid calling it outside of
IRQ context.
Signed-off-by: Jibin Xu <jibin.xu(a)windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/sysrq.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -246,8 +246,10 @@ static void sysrq_handle_showallcpus(int
* architecture has no support for it:
*/
if (!trigger_all_cpu_backtrace()) {
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+ if (in_irq())
+ regs = get_irq_regs();
if (regs) {
pr_info("CPU%d:\n", smp_processor_id());
show_regs(regs);
@@ -266,7 +268,10 @@ static struct sysrq_key_op sysrq_showall
static void sysrq_handle_showregs(int key)
{
- struct pt_regs *regs = get_irq_regs();
+ struct pt_regs *regs = NULL;
+
+ if (in_irq())
+ regs = get_irq_regs();
if (regs)
show_regs(regs);
perf_event_print_debug();
Patches currently in stable-queue which might be from jibin.xu(a)windriver.com are
queue-4.14/sysrq-fix-show-regs-call-trace-on-arm.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8822be: Keep array subscript no lower than zero
to the 4.14-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:
staging-rtl8822be-keep-array-subscript-no-lower-than-zero.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Larry Finger <Larry.Finger(a)lwfinger.net>
Date: Sat, 23 Sep 2017 19:36:04 -0500
Subject: staging: rtl8822be: Keep array subscript no lower than zero
From: Larry Finger <Larry.Finger(a)lwfinger.net>
[ Upstream commit 43d15c2013130a9fa230c2f5203aca818ae0bb86 ]
The kbuild test robot reports the following:
drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 'odm_pause_dig':
drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript is below array bounds [-Warray-bounds]
odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);
This condition is caused when a loop falls through. The fix is to pin
max_level to be >= 0.
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
c: kbuild test robot <fengguang.wu(a)intel.com>
Fixes: 9ce99b04b5b82fdf11e4c76b60a5f82c1e541297 staging: r8822be: Add phydm mini driver
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtlwifi/phydm/phydm_dig.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/staging/rtlwifi/phydm/phydm_dig.c
+++ b/drivers/staging/rtlwifi/phydm/phydm_dig.c
@@ -490,6 +490,8 @@ void odm_pause_dig(void *dm_void, enum p
break;
}
+ /* pin max_level to be >= 0 */
+ max_level = max_t(s8, 0, max_level);
/* write IGI of lower level */
odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);
ODM_RT_TRACE(dm, ODM_COMP_DIG,
Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are
queue-4.14/staging-rtl8822be-fix-wrong-dma-unmap-len.patch
queue-4.14/staging-rtl8822be-keep-array-subscript-no-lower-than-zero.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8822be: fix wrong dma unmap len
to the 4.14-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:
staging-rtl8822be-fix-wrong-dma-unmap-len.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Stanislaw Gruszka <sgruszka(a)redhat.com>
Date: Mon, 23 Oct 2017 11:35:59 +0200
Subject: staging: rtl8822be: fix wrong dma unmap len
From: Stanislaw Gruszka <sgruszka(a)redhat.com>
[ Upstream commit c40a45a465e9eab72cfdd3ab69d15cf8ef8b89c8 ]
Patch fixes splat:
r8822be 0000:04:00.0: DMA-API: device driver frees DMA memory with different size
[device address=0x0000000078477000] [map size=4096 bytes] [unmap size=424 bytes]
<snip>
Call Trace:
debug_dma_unmap_page+0xa5/0xb0
? unmap_single+0x2f/0x40
_rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be]
? _rtl8822be_send_bcn_or_cmd_packet+0x2c5/0x300 [r8822be]
rtl8822b_halmac_cb_write_data_rsvd_page+0x51/0xc0 [r8822be]
_halmac_write_data_rsvd_page+0x22/0x30 [r8822be]
halmac_download_rsvd_page_88xx+0xee/0x1f0 [r8822be]
halmac_dlfw_to_mem_88xx+0x80/0x120 [r8822be]
halmac_download_firmware_88xx.part.47+0x477/0x600 [r8822be]
halmac_download_firmware_88xx+0x32/0x40 [r8822be]
rtl_halmac_dlfw+0x70/0x120 [r8822be]
rtl_halmac_init_hal+0x5f/0x1b0 [r8822be]
rtl8822be_hw_init+0x8a2/0x1040 [r8822be]
Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com>
Acked-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtlwifi/rtl8822be/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -419,7 +419,7 @@ static bool _rtl8822be_send_bcn_or_cmd_p
dma_addr = rtlpriv->cfg->ops->get_desc(
hw, (u8 *)pbd_desc, true, HW_DESC_TXBUFF_ADDR);
- pci_unmap_single(rtlpci->pdev, dma_addr, skb->len,
+ pci_unmap_single(rtlpci->pdev, dma_addr, pskb->len,
PCI_DMA_TODEVICE);
kfree_skb(pskb);
Patches currently in stable-queue which might be from sgruszka(a)redhat.com are
queue-4.14/staging-rtl8822be-fix-wrong-dma-unmap-len.patch
This is a note to let you know that I've just added the patch titled
staging: rtl8188eu: avoid a null dereference on pmlmepriv
to the 4.14-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:
staging-rtl8188eu-avoid-a-null-dereference-on-pmlmepriv.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 20 Oct 2017 20:40:24 +0200
Subject: staging: rtl8188eu: avoid a null dereference on pmlmepriv
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit 123c0aab0050cd0e07ce18e453389fbbb0a5a425 ]
There is a check on pmlmepriv before dereferencing it when
vfree'ing pmlmepriv->free_bss_buf however the previous call
to rtw_free_mlme_priv_ie_data deferences pmlmepriv causing
a null pointer deference if it is null. Avoid this by also
calling rtw_free_mlme_priv_ie_data if the pointer is non-null.
Detected by CoverityScan, CID#1230262 ("Dereference before null check")
Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -106,10 +106,10 @@ void rtw_free_mlme_priv_ie_data(struct m
void rtw_free_mlme_priv(struct mlme_priv *pmlmepriv)
{
- rtw_free_mlme_priv_ie_data(pmlmepriv);
-
- if (pmlmepriv)
+ if (pmlmepriv) {
+ rtw_free_mlme_priv_ie_data(pmlmepriv);
vfree(pmlmepriv->free_bss_buf);
+ }
}
struct wlan_network *_rtw_alloc_network(struct mlme_priv *pmlmepriv)
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/staging-rtl8188eu-avoid-a-null-dereference-on-pmlmepriv.patch
This is a note to let you know that I've just added the patch titled
staging: greybus: loopback: Fix iteration count on async path
to the 4.14-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:
staging-greybus-loopback-fix-iteration-count-on-async-path.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Date: Mon, 6 Nov 2017 01:32:20 +0000
Subject: staging: greybus: loopback: Fix iteration count on async path
From: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
[ Upstream commit 44b02da39210e6dd67e39ff1f48d30c56d384240 ]
Commit 12927835d211 ("greybus: loopback: Add asynchronous bi-directional
support") does what it says on the tin - namely, adds support for
asynchronous bi-directional loopback operations.
What it neglects to do though is increment the per-connection
gb->iteration_count on an asynchronous operation error. This patch fixes
that omission.
Fixes: 12927835d211 ("greybus: loopback: Add asynchronous bi-directional support")
Signed-off-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Reported-by: Mitch Tasman <tasman(a)leaflabs.com>
Reviewed-by: Johan Hovold <johan(a)kernel.org>
Cc: Alex Elder <elder(a)kernel.org>
Cc: Mitch Tasman <tasman(a)leaflabs.com>
Cc: greybus-dev(a)lists.linaro.org
Cc: devel(a)driverdev.osuosl.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/greybus/loopback.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1042,8 +1042,10 @@ static int gb_loopback_fn(void *data)
else if (type == GB_LOOPBACK_TYPE_SINK)
error = gb_loopback_async_sink(gb, size);
- if (error)
+ if (error) {
gb->error++;
+ gb->iteration_count++;
+ }
} else {
/* We are effectively single threaded here */
if (type == GB_LOOPBACK_TYPE_PING)
Patches currently in stable-queue which might be from pure.logic(a)nexus-software.ie are
queue-4.14/staging-greybus-loopback-fix-iteration-count-on-async-path.patch
This is a note to let you know that I've just added the patch titled
staging: fsl-mc/dpio: Fix incorrect comparison
to the 4.14-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:
staging-fsl-mc-dpio-fix-incorrect-comparison.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Ioana Radulescu <ruxandra.radulescu(a)nxp.com>
Date: Thu, 28 Sep 2017 09:10:33 -0500
Subject: staging: fsl-mc/dpio: Fix incorrect comparison
From: Ioana Radulescu <ruxandra.radulescu(a)nxp.com>
[ Upstream commit 8dabf52ffb6445fa5bcc8b6d2ecb615f60d0dd12 ]
For some dpio functions, a cpu id parameter value of -1 is
valid and means "any". But when trying to validate this param
value against an upper limit, in this case num_possible_cpus(),
we risk obtaining the wrong result due to an implicit cast.
Avoid an incorrect check result by explicitly comparing the
cpu id with the "any" value before verifying the upper bound.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/fsl-mc/bus/dpio/dpio-service.c | 4 ++--
drivers/staging/fsl-mc/include/dpaa2-io.h | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
+++ b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
@@ -76,7 +76,7 @@ static inline struct dpaa2_io *service_s
if (d)
return d;
- if (unlikely(cpu >= num_possible_cpus()))
+ if (cpu != DPAA2_IO_ANY_CPU && cpu >= num_possible_cpus())
return NULL;
/*
@@ -121,7 +121,7 @@ struct dpaa2_io *dpaa2_io_create(const s
return NULL;
/* check if CPU is out of range (-1 means any cpu) */
- if (desc->cpu >= num_possible_cpus()) {
+ if (desc->cpu != DPAA2_IO_ANY_CPU && desc->cpu >= num_possible_cpus()) {
kfree(obj);
return NULL;
}
--- a/drivers/staging/fsl-mc/include/dpaa2-io.h
+++ b/drivers/staging/fsl-mc/include/dpaa2-io.h
@@ -54,6 +54,8 @@ struct device;
* for dequeue.
*/
+#define DPAA2_IO_ANY_CPU -1
+
/**
* struct dpaa2_io_desc - The DPIO descriptor
* @receives_notifications: Use notificaton mode. Non-zero if the DPIO
@@ -91,8 +93,8 @@ irqreturn_t dpaa2_io_irq(struct dpaa2_io
* @cb: The callback to be invoked when the notification arrives
* @is_cdan: Zero for FQDAN, non-zero for CDAN
* @id: FQID or channel ID, needed for rearm
- * @desired_cpu: The cpu on which the notifications will show up. -1 means
- * any CPU.
+ * @desired_cpu: The cpu on which the notifications will show up. Use
+ * DPAA2_IO_ANY_CPU if don't care
* @dpio_id: The dpio index
* @qman64: The 64-bit context value shows up in the FQDAN/CDAN.
* @node: The list node
Patches currently in stable-queue which might be from ruxandra.radulescu(a)nxp.com are
queue-4.14/staging-fsl-dpaa2-eth-account-for-rx-fd-buffers-on-error-path.patch
queue-4.14/staging-fsl-mc-dpio-fix-incorrect-comparison.patch
This is a note to let you know that I've just added the patch titled
staging: fsl-dpaa2/eth: Account for Rx FD buffers on error path
to the 4.14-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:
staging-fsl-dpaa2-eth-account-for-rx-fd-buffers-on-error-path.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Ioana Radulescu <ruxandra.radulescu(a)nxp.com>
Date: Wed, 11 Oct 2017 08:29:44 -0500
Subject: staging: fsl-dpaa2/eth: Account for Rx FD buffers on error path
From: Ioana Radulescu <ruxandra.radulescu(a)nxp.com>
[ Upstream commit cbb3ea40fc495bf04070200b35c1c4cd05d11bd3 ]
On Rx path, if we fail to build an skb from the incoming FD,
we still need to update the channel buffer count accordingly,
otherwise we risk depleting the pool while the software counter
still sees available buffers.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -131,6 +131,8 @@ static struct sk_buff *build_linear_skb(
u16 fd_offset = dpaa2_fd_get_offset(fd);
u32 fd_length = dpaa2_fd_get_len(fd);
+ ch->buf_count--;
+
skb = build_skb(fd_vaddr, DPAA2_ETH_RX_BUF_SIZE +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
if (unlikely(!skb))
@@ -139,8 +141,6 @@ static struct sk_buff *build_linear_skb(
skb_reserve(skb, fd_offset);
skb_put(skb, fd_length);
- ch->buf_count--;
-
return skb;
}
@@ -178,8 +178,15 @@ static struct sk_buff *build_frag_skb(st
/* We build the skb around the first data buffer */
skb = build_skb(sg_vaddr, DPAA2_ETH_RX_BUF_SIZE +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
- if (unlikely(!skb))
- return NULL;
+ if (unlikely(!skb)) {
+ /* We still need to subtract the buffers used
+ * by this FD from our software counter
+ */
+ while (!dpaa2_sg_is_final(&sgt[i]) &&
+ i < DPAA2_ETH_MAX_SG_ENTRIES)
+ i++;
+ break;
+ }
sg_offset = dpaa2_sg_get_offset(sge);
skb_reserve(skb, sg_offset);
Patches currently in stable-queue which might be from ruxandra.radulescu(a)nxp.com are
queue-4.14/staging-fsl-dpaa2-eth-account-for-rx-fd-buffers-on-error-path.patch
queue-4.14/staging-fsl-mc-dpio-fix-incorrect-comparison.patch
This is a note to let you know that I've just added the patch titled
spi: spi-axi: fix potential use-after-free after deregistration
to the 4.14-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:
spi-spi-axi-fix-potential-use-after-free-after-deregistration.patch
and it can be found in the queue-4.14 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 Wed Dec 6 18:04:41 CET 2017
From: Johan Hovold <johan(a)kernel.org>
Date: Mon, 30 Oct 2017 11:35:27 +0100
Subject: spi: spi-axi: fix potential use-after-free after deregistration
From: Johan Hovold <johan(a)kernel.org>
[ Upstream commit 4d5e0689dc9d5640ad46cdfbe1896b74d8df1661 ]
Take an extra reference to the controller before deregistering it to
prevent use-after-free in the interrupt handler in case an interrupt
fires before the line is disabled.
Fixes: b1353d1c1d45 ("spi: Add Analog Devices AXI SPI Engine controller support")
Acked-by: Lars-Peter Clausen <lars(a)metafoo.de>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-axi-spi-engine.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -553,7 +553,7 @@ err_put_master:
static int spi_engine_remove(struct platform_device *pdev)
{
- struct spi_master *master = platform_get_drvdata(pdev);
+ struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct spi_engine *spi_engine = spi_master_get_devdata(master);
int irq = platform_get_irq(pdev, 0);
@@ -561,6 +561,8 @@ static int spi_engine_remove(struct plat
free_irq(irq, master);
+ spi_master_put(master);
+
writel_relaxed(0xff, spi_engine->base + SPI_ENGINE_REG_INT_PENDING);
writel_relaxed(0x00, spi_engine->base + SPI_ENGINE_REG_INT_ENABLE);
writel_relaxed(0x01, spi_engine->base + SPI_ENGINE_REG_RESET);
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.14/staging-greybus-loopback-fix-iteration-count-on-async-path.patch
queue-4.14/usb-serial-usb_debug-add-new-usb-device-id.patch
queue-4.14/spi-spi-axi-fix-potential-use-after-free-after-deregistration.patch
queue-4.14/usb-serial-option-add-quectel-bg96-id.patch