This is a note to let you know that I've just added the patch titled
x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
to the 4.9-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:
x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: Kevin Hao <haokexin(a)gmail.com>
Date: Sun, 22 Jan 2017 16:50:23 +0800
Subject: x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
From: Kevin Hao <haokexin(a)gmail.com>
[ Upstream commit 4c833368f0bf748d4147bf301b1f95bc8eccb3c0 ]
I got the following calltrace on a Apollo Lake SoC with 32-bit kernel:
WARNING: CPU: 2 PID: 261 at arch/x86/include/asm/fpu/internal.h:363 fpu__restore+0x1f5/0x260
[...]
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLIRVPA.X64.0138.B35.1608091058 08/09/2016
Call Trace:
dump_stack()
__warn()
? fpu__restore()
warn_slowpath_null()
fpu__restore()
__fpu__restore_sig()
fpu__restore_sig()
restore_sigcontext.isra.9()
sys_sigreturn()
do_int80_syscall_32()
entry_INT80_32()
The reason is that a #GP occurs when executing XRSTORS. The root cause
is that we forget to set the xcomp_bv when we fake up the XSAVES area
in the copyin_to_xsaves() function.
Signed-off-by: Kevin Hao <haokexin(a)gmail.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: Fenghua Yu <fenghua.yu(a)intel.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Quentin Casasnovas <quentin.casasnovas(a)oracle.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Yu-cheng Yu <yu-cheng.yu(a)intel.com>
Link: http://lkml.kernel.org/r/1485075023-30161-1-git-send-email-haokexin@gmail.c…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/fpu/xstate.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1077,6 +1077,7 @@ int copyin_to_xsaves(const void *kbuf, c
* Add back in the features that came in from userspace:
*/
xsave->header.xfeatures |= xfeatures;
+ xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT | xsave->header.xfeatures;
return 0;
}
Patches currently in stable-queue which might be from haokexin(a)gmail.com are
queue-4.9/x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
This is a note to let you know that I've just added the patch titled
x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
to the 4.9-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:
x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: Dave Hansen <dave.hansen(a)linux.intel.com>
Date: Wed, 18 Oct 2017 10:21:07 -0700
Subject: x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt()
From: Dave Hansen <dave.hansen(a)linux.intel.com>
[ Upstream commit da20ab35180780e4a6eadc804544f1fa967f3567 ]
We do not have tracepoints for sys_modify_ldt() because we define
it directly instead of using the normal SYSCALL_DEFINEx() macros.
However, there is a reason sys_modify_ldt() does not use the macros:
it has an 'int' return type instead of 'unsigned long'. This is
a bug, but it's a bug cemented in the ABI.
What does this mean? If we return -EINVAL from a function that
returns 'int', we have 0x00000000ffffffea in %rax. But, if we
return -EINVAL from a function returning 'unsigned long', we end
up with 0xffffffffffffffea in %rax, which is wrong.
To work around this and maintain the 'int' behavior while using
the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
in both implementations of sys_modify_ldt().
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Andy Lutomirski <luto(a)kernel.org>
Reviewed-by: Brian Gerst <brgerst(a)gmail.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20171018172107.1A79C532@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/syscalls.h | 2 +-
arch/x86/kernel/ldt.c | 16 +++++++++++++---
arch/x86/um/ldt.c | 7 +++++--
3 files changed, 19 insertions(+), 6 deletions(-)
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -21,7 +21,7 @@ asmlinkage long sys_ioperm(unsigned long
asmlinkage long sys_iopl(unsigned int);
/* kernel/ldt.c */
-asmlinkage int sys_modify_ldt(int, void __user *, unsigned long);
+asmlinkage long sys_modify_ldt(int, void __user *, unsigned long);
/* kernel/signal.c */
asmlinkage long sys_rt_sigreturn(void);
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -12,6 +12,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/smp.h>
+#include <linux/syscalls.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/uaccess.h>
@@ -271,8 +272,8 @@ out:
return error;
}
-asmlinkage int sys_modify_ldt(int func, void __user *ptr,
- unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
int ret = -ENOSYS;
@@ -290,5 +291,14 @@ asmlinkage int sys_modify_ldt(int func,
ret = write_ldt(ptr, bytecount, 0);
break;
}
- return ret;
+ /*
+ * The SYSCALL_DEFINE() macros give us an 'unsigned long'
+ * return type, but tht ABI for sys_modify_ldt() expects
+ * 'int'. This cast gives us an int-sized value in %rax
+ * for the return code. The 'unsigned' is necessary so
+ * the compiler does not try to sign-extend the negative
+ * return codes into the high half of the register when
+ * taking the value from int->long.
+ */
+ return (unsigned int)ret;
}
--- a/arch/x86/um/ldt.c
+++ b/arch/x86/um/ldt.c
@@ -6,6 +6,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/syscalls.h>
#include <linux/uaccess.h>
#include <asm/unistd.h>
#include <os.h>
@@ -369,7 +370,9 @@ void free_ldt(struct mm_context *mm)
mm->arch.ldt.entry_count = 0;
}
-int sys_modify_ldt(int func, void __user *ptr, unsigned long bytecount)
+SYSCALL_DEFINE3(modify_ldt, int , func , void __user * , ptr ,
+ unsigned long , bytecount)
{
- return do_modify_ldt_skas(func, ptr, bytecount);
+ /* See non-um modify_ldt() for why we do this cast */
+ return (unsigned int)do_modify_ldt_skas(func, ptr, bytecount);
}
Patches currently in stable-queue which might be from dave.hansen(a)linux.intel.com are
queue-4.9/x86-entry-use-syscall_define-macros-for-sys_modify_ldt.patch
queue-4.9/x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
This is a note to let you know that I've just added the patch titled
vti6: fix device register to report IFLA_INFO_KIND
to the 4.9-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:
vti6-fix-device-register-to-report-ifla_info_kind.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: David Forster <dforster(a)brocade.com>
Date: Fri, 6 Jan 2017 10:27:59 +0000
Subject: vti6: fix device register to report IFLA_INFO_KIND
From: David Forster <dforster(a)brocade.com>
[ Upstream commit 93e246f783e6bd1bc64fdfbfe68b18161f69b28e ]
vti6 interface is registered before the rtnl_link_ops block
is attached. As a result the resulting RTM_NEWLINK is missing
IFLA_INFO_KIND. Re-order attachment of rtnl_link_ops block to fix.
Signed-off-by: Dave Forster <dforster(a)brocade.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_vti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -189,12 +189,12 @@ static int vti6_tnl_create2(struct net_d
struct vti6_net *ip6n = net_generic(net, vti6_net_id);
int err;
+ dev->rtnl_link_ops = &vti6_link_ops;
err = register_netdevice(dev);
if (err < 0)
goto out;
strcpy(t->parms.name, dev->name);
- dev->rtnl_link_ops = &vti6_link_ops;
dev_hold(dev);
vti6_tnl_link(ip6n, t);
Patches currently in stable-queue which might be from dforster(a)brocade.com are
queue-4.9/vti6-fix-device-register-to-report-ifla_info_kind.patch
This is a note to let you know that I've just added the patch titled
vfio/spapr: Fix missing mutex unlock when creating a window
to the 4.9-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:
vfio-spapr-fix-missing-mutex-unlock-when-creating-a-window.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Date: Wed, 1 Feb 2017 14:26:16 +1100
Subject: vfio/spapr: Fix missing mutex unlock when creating a window
From: Alexey Kardashevskiy <aik(a)ozlabs.ru>
[ Upstream commit 2da64d20a0b20046d688e44f4033efd09157e29d ]
Commit d9c728949ddc ("vfio/spapr: Postpone default window creation")
added an additional exit to the VFIO_IOMMU_SPAPR_TCE_CREATE case and
made it possible to return from tce_iommu_ioctl() without unlocking
container->lock; this fixes the issue.
Fixes: d9c728949ddc ("vfio/spapr: Postpone default window creation")
Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vfio/vfio_iommu_spapr_tce.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -1123,12 +1123,11 @@ static long tce_iommu_ioctl(void *iommu_
mutex_lock(&container->lock);
ret = tce_iommu_create_default_window(container);
- if (ret)
- return ret;
-
- ret = tce_iommu_create_window(container, create.page_shift,
- create.window_size, create.levels,
- &create.start_addr);
+ if (!ret)
+ ret = tce_iommu_create_window(container,
+ create.page_shift,
+ create.window_size, create.levels,
+ &create.start_addr);
mutex_unlock(&container->lock);
Patches currently in stable-queue which might be from aik(a)ozlabs.ru are
queue-4.9/vfio-spapr-fix-missing-mutex-unlock-when-creating-a-window.patch
This is a note to let you know that I've just added the patch titled
usbip: tools: Install all headers needed for libusbip development
to the 4.9-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:
usbip-tools-install-all-headers-needed-for-libusbip-development.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: Ben Hutchings <ben(a)decadent.org.uk>
Date: Sun, 1 Oct 2017 02:18:37 +0100
Subject: usbip: tools: Install all headers needed for libusbip development
From: Ben Hutchings <ben(a)decadent.org.uk>
[ Upstream commit c15562c0dcb2c7f26e891923b784cf1926b8c833 ]
usbip_host_driver.h now depends on several additional headers, which
need to be installed along with it.
Fixes: 021aed845303 ("staging: usbip: userspace: migrate usbip_host_driver ...")
Fixes: 3391ba0e2792 ("usbip: tools: Extract generic code to be shared with ...")
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.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>
---
tools/usb/usbip/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/usb/usbip/Makefile.am
+++ b/tools/usb/usbip/Makefile.am
@@ -1,6 +1,7 @@
SUBDIRS := libsrc src
includedir = @includedir@/usbip
include_HEADERS := $(addprefix libsrc/, \
- usbip_common.h vhci_driver.h usbip_host_driver.h)
+ usbip_common.h vhci_driver.h usbip_host_driver.h \
+ list.h sysfs_utils.h usbip_host_common.h)
dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
Patches currently in stable-queue which might be from ben(a)decadent.org.uk are
queue-4.9/usbip-tools-install-all-headers-needed-for-libusbip-development.patch
This is a note to let you know that I've just added the patch titled
USB: serial: option: add Quectel BG96 id
to the 4.9-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-serial-option-add-quectel-bg96-id.patch
and it can be found in the queue-4.9 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 c654b21ede93845863597de9ad774fd30db5f2ab Mon Sep 17 00:00:00 2001
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
Date: Mon, 20 Nov 2017 19:29:32 +0100
Subject: USB: serial: option: add Quectel BG96 id
From: Sebastian Sjoholm <ssjoholm(a)mac.com>
commit c654b21ede93845863597de9ad774fd30db5f2ab upstream.
Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
development board (EVB). The USB id is added to option.c to allow
DIAG,GPS,AT and modem communication with the BG96.
Signed-off-by: Sebastian Sjoholm <ssjoholm(a)mac.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struc
/* These Quectel products use Quectel's vendor ID */
#define QUECTEL_PRODUCT_EC21 0x0121
#define QUECTEL_PRODUCT_EC25 0x0125
+#define QUECTEL_PRODUCT_BG96 0x0296
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1185,6 +1186,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
Patches currently in stable-queue which might be from ssjoholm(a)mac.com are
queue-4.9/usb-serial-option-add-quectel-bg96-id.patch
This is a note to let you know that I've just added the patch titled
usb: phy: tahvo: fix error handling in tahvo_usb_probe()
to the 4.9-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-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 21 Oct 2017 01:02:07 +0300
Subject: usb: phy: tahvo: fix error handling in tahvo_usb_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit ce035409bfa892a2fabb89720b542e1b335c3426 ]
If devm_extcon_dev_allocate() fails, we should disable clk before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Fixes: 860d2686fda7 ("usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API")
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/phy/phy-tahvo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -368,7 +368,8 @@ static int tahvo_usb_probe(struct platfo
tu->extcon = devm_extcon_dev_allocate(&pdev->dev, tahvo_cable);
if (IS_ERR(tu->extcon)) {
dev_err(&pdev->dev, "failed to allocate memory for extcon\n");
- return -ENOMEM;
+ ret = PTR_ERR(tu->extcon);
+ goto err_disable_clk;
}
ret = devm_extcon_dev_register(&pdev->dev, tu->extcon);
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.9/usb-phy-tahvo-fix-error-handling-in-tahvo_usb_probe.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix ExtCompat descriptor validation
to the 4.9-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-gadget-f_fs-fix-extcompat-descriptor-validation.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: Vincent Pelletier <plr.vincent(a)gmail.com>
Date: Thu, 15 Dec 2016 12:47:42 +0000
Subject: usb: gadget: f_fs: Fix ExtCompat descriptor validation
From: Vincent Pelletier <plr.vincent(a)gmail.com>
[ Upstream commit 354bc45bf329494ef6051f3229ef50b9e2a7ea2a ]
Reserved1 is documented as expected to be set to 0, but this test fails
when it it set to 0. Reverse the condition.
Signed-off-by: Vincent Pelletier <plr.vincent(a)gmail.com>
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/gadget/function/f_fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2263,7 +2263,7 @@ static int __ffs_data_do_os_desc(enum ff
if (len < sizeof(*d) ||
d->bFirstInterfaceNumber >= ffs->interfaces_count ||
- !d->Reserved1)
+ d->Reserved1)
return -EINVAL;
for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i)
if (d->Reserved2[i])
Patches currently in stable-queue which might be from plr.vincent(a)gmail.com are
queue-4.9/usb-gadget-f_fs-fix-extcompat-descriptor-validation.patch
This is a note to let you know that I've just added the patch titled
usb: dwc2: Fix UDC state tracking
to the 4.9-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-fix-udc-state-tracking.patch
and it can be found in the queue-4.9 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 17:39:55 CET 2017
From: John Stultz <john.stultz(a)linaro.org>
Date: Mon, 23 Oct 2017 14:32:50 -0700
Subject: usb: dwc2: Fix UDC state tracking
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]
It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c0000.usb/state file would
report "configured" no matter the state of the OTG port.
This patch adds a call so that we report to the UDC layer when
the gadget device is disconnected.
This patch does depend on the previous patch ("usb: dwc2:
Improve gadget state disconnection handling") in this patch set
in order to properly work.
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: Amit Pundir <amit.pundir(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 | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2467,6 +2467,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
call_gadget(hsotg, disconnect);
hsotg->lx_state = DWC2_L3;
+
+ usb_gadget_set_state(&hsotg->gadget, USB_STATE_NOTATTACHED);
}
/**
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.9/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.9/usb-dwc2-fix-udc-state-tracking.patch
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.9-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.9 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 17:39:55 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
@@ -3117,6 +3117,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.9/usb-dwc2-error-out-of-dwc2_hsotg_ep_disable-if-we-re-in-host-mode.patch
queue-4.9/usb-dwc2-fix-udc-state-tracking.patch