* [PATCH 4.13 01/28] media: imon: Fix null-ptr-deref in imon_probe
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 02/28] media: dib0700: fix invalid dvb_detach argument Greg Kroah-Hartman
` (27 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Yadav, Andrey Konovalov,
Sean Young, Mauro Carvalho Chehab, Ben Hutchings
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
commit 58fd55e838276a0c13d1dc7c387f90f25063cbf3 upstream.
It seems that the return value of usb_ifnum_to_if() can be NULL and
needs to be checked.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/rc/imon.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2516,6 +2516,11 @@ static int imon_probe(struct usb_interfa
mutex_lock(&driver_lock);
first_if = usb_ifnum_to_if(usbdev, 0);
+ if (!first_if) {
+ ret = -ENODEV;
+ goto fail;
+ }
+
first_if_ctx = usb_get_intfdata(first_if);
if (ifnum == 0) {
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 02/28] media: dib0700: fix invalid dvb_detach argument
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 01/28] media: imon: Fix null-ptr-deref in imon_probe Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume Greg Kroah-Hartman
` (26 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrey Konovalov, Ben Hutchings,
Mauro Carvalho Chehab
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Konovalov <andreyknvl@google.com>
commit eb0c19942288569e0ae492476534d5a485fb8ab4 upstream.
dvb_detach(arg) calls symbol_put_addr(arg), where arg should be a pointer
to a function. Right now a pointer to state->dib7000p_ops is passed to
dvb_detach(), which causes a BUG() in symbol_put_addr() as discovered by
syzkaller. Pass state->dib7000p_ops.set_wbd_ref instead.
------------[ cut here ]------------
kernel BUG at kernel/module.c:1081!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1151 Comm: kworker/1:1 Tainted: G W
4.14.0-rc1-42251-gebb2c2437d80 #224
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006a336300 task.stack: ffff88006a7c8000
RIP: 0010:symbol_put_addr+0x54/0x60 kernel/module.c:1083
RSP: 0018:ffff88006a7ce210 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880062a8d190 RCX: 0000000000000000
RDX: dffffc0000000020 RSI: ffffffff85876d60 RDI: ffff880062a8d190
RBP: ffff88006a7ce218 R08: 1ffff1000d4f9c12 R09: 1ffff1000d4f9ae4
R10: 1ffff1000d4f9bed R11: 0000000000000000 R12: ffff880062a8d180
R13: 00000000ffffffed R14: ffff880062a8d190 R15: ffff88006947c000
FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6416532000 CR3: 00000000632f5000 CR4: 00000000000006e0
Call Trace:
stk7070p_frontend_attach+0x515/0x610
drivers/media/usb/dvb-usb/dib0700_devices.c:1013
dvb_usb_adapter_frontend_init+0x32b/0x660
drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286
dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86
dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162
dvb_usb_device_init+0xf70/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277
dib0700_probe+0x171/0x5a0 drivers/media/usb/dvb-usb/dib0700_core.c:886
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: ff ff 48 85 c0 74 24 48 89 c7 e8 48 ea ff ff bf 01 00 00 00 e8
de 20 e3 ff 65 8b 05 b7 2f c2 7e 85 c0 75 c9 e8 f9 0b c1 ff eb c2 <0f>
0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 b8 00 00
RIP: symbol_put_addr+0x54/0x60 RSP: ffff88006a7ce210
---[ end trace b75b357739e7e116 ]---
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/dib0700_devices.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -291,7 +291,7 @@ static int stk7700P2_frontend_attach(str
stk7700d_dib7000p_mt2266_config)
!= 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
}
@@ -325,7 +325,7 @@ static int stk7700d_frontend_attach(stru
stk7700d_dib7000p_mt2266_config)
!= 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
}
@@ -478,7 +478,7 @@ static int stk7700ph_frontend_attach(str
&stk7700ph_dib7700_xc3028_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n",
__func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
@@ -1010,7 +1010,7 @@ static int stk7070p_frontend_attach(stru
&dib7070p_dib7000p_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n",
__func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
@@ -1068,7 +1068,7 @@ static int stk7770p_frontend_attach(stru
&dib7770p_dib7000p_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n",
__func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
@@ -3056,7 +3056,7 @@ static int nim7090_frontend_attach(struc
if (state->dib7000p_ops.i2c_enumeration(&adap->dev->i2c_adap, 1, 0x10, &nim7090_dib7000p_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
adap->fe_adap[0].fe = state->dib7000p_ops.init(&adap->dev->i2c_adap, 0x80, &nim7090_dib7000p_config);
@@ -3109,7 +3109,7 @@ static int tfe7090pvr_frontend0_attach(s
/* initialize IC 0 */
if (state->dib7000p_ops.i2c_enumeration(&adap->dev->i2c_adap, 1, 0x20, &tfe7090pvr_dib7000p_config[0]) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
@@ -3139,7 +3139,7 @@ static int tfe7090pvr_frontend1_attach(s
i2c = state->dib7000p_ops.get_i2c_master(adap->dev->adapter[0].fe_adap[0].fe, DIBX000_I2C_INTERFACE_GPIO_6_7, 1);
if (state->dib7000p_ops.i2c_enumeration(i2c, 1, 0x10, &tfe7090pvr_dib7000p_config[1]) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n", __func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
@@ -3214,7 +3214,7 @@ static int tfe7790p_frontend_attach(stru
1, 0x10, &tfe7790p_dib7000p_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n",
__func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
adap->fe_adap[0].fe = state->dib7000p_ops.init(&adap->dev->i2c_adap,
@@ -3309,7 +3309,7 @@ static int stk7070pd_frontend_attach0(st
stk7070pd_dib7000p_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n",
__func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
@@ -3384,7 +3384,7 @@ static int novatd_frontend_attach(struct
stk7070pd_dib7000p_config) != 0) {
err("%s: state->dib7000p_ops.i2c_enumeration failed. Cannot continue\n",
__func__);
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
}
@@ -3620,7 +3620,7 @@ static int pctv340e_frontend_attach(stru
if (state->dib7000p_ops.dib7000pc_detection(&adap->dev->i2c_adap) == 0) {
/* Demodulator not found for some reason? */
- dvb_detach(&state->dib7000p_ops);
+ dvb_detach(state->dib7000p_ops.set_wbd_ref);
return -ENODEV;
}
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 01/28] media: imon: Fix null-ptr-deref in imon_probe Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 02/28] media: dib0700: fix invalid dvb_detach argument Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-12-16 3:05 ` Matthias Kaehlcke
2017-11-19 14:43 ` [PATCH 4.13 04/28] crypto: dh - Fix double free of ctx->p Greg Kroah-Hartman
` (25 subsequent siblings)
28 siblings, 1 reply; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Leif Liddy, Marcel Holtmann,
Kai Heng Feng
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leif Liddy <leif.linux@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@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3068,6 +3068,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
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-11-19 14:43 ` [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume Greg Kroah-Hartman
@ 2017-12-16 3:05 ` Matthias Kaehlcke
2017-12-18 5:16 ` Kai Heng Feng
2017-12-18 11:43 ` Greg Kroah-Hartman
0 siblings, 2 replies; 45+ messages in thread
From: Matthias Kaehlcke @ 2017-12-16 3:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Leif Liddy, Marcel Holtmann, Kai Heng Feng,
Brian Norris, Guenter Roeck
Hi,
El Sun, Nov 19, 2017 at 03:43:50PM +0100 Greg Kroah-Hartman ha dit:
> 4.13-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Leif Liddy <leif.linux@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@gmail.com>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/bluetooth/btusb.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3068,6 +3068,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
>
>
On Chrome OS QCA Bluetooth stopped working after a merge from v4.4-stable:
[ 124.789298] usb 2-1.1: reset full-speed USB device number 3 using ehci-platform
[ 126.624274] Bluetooth: hci0 command 0x2005 tx timeout
[ 128.672262] Bluetooth: hci0 command 0x200b tx timeout
[ 130.720264] Bluetooth: hci0 command 0x200c tx timeout
We identified the above patch as the culprit, in combination with USB
autosuspend being enabled for the Bluetooth controller.
We found that the following (recent) upstream patch fixes the issue on
most devices (we are still investigating one case on a specific device):
commit a0085f2510e8976614ad8f766b209448b385492f
Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
Date: Wed Aug 16 14:46:55 2017 -0700
Bluetooth: btusb: driver to enable the usb-wakeup feature
BT-Controller connected as platform non-root-hub device and
usb-driver initialize such device with wakeup disabled,
Ref. usb_new_device().
At present wakeup-capability get enabled by hid-input device from usb
function driver(e.g. BT HID device) at runtime. Again some functional
driver does not set usb-wakeup capability(e.g LE HID device implement
as HID-over-GATT), and can't wakeup the host on USB.
Most of the device operation (such as mass storage) initiated from host
(except HID) and USB wakeup aligned with host resume procedure. For BT
device, usb-wakeup capability need to enable form btusc driver as a
generic solution for multiple profile use case and required for USB remote
wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature
need to enable/disable with HCI interface up and down.
stable branches are currently broken for BTUSB_QCA_ROME with USB
autosuspend enabled, since the above patch is not included (I only
checked v4.4 and v4.9), so we probably want to integrate it.
Thanks
Matthias
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-12-16 3:05 ` Matthias Kaehlcke
@ 2017-12-18 5:16 ` Kai Heng Feng
2017-12-18 11:43 ` Greg Kroah-Hartman
1 sibling, 0 replies; 45+ messages in thread
From: Kai Heng Feng @ 2017-12-18 5:16 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Greg Kroah-Hartman, LKML, stable, Leif Liddy, Marcel Holtmann,
Brian Norris, Guenter Roeck
Hi,
> On 16 Dec 2017, at 11:05 AM, Matthias Kaehlcke <mka@chromium.org> wrote:
> stable branches are currently broken for BTUSB_QCA_ROME with USB
> autosuspend enabled, since the above patch is not included (I only
> checked v4.4 and v4.9), so we probably want to integrate it.
Thanks for this information.
I just found the same issue and I can confirm your finding.
I was testing with runtime suspend disabled.
Once the runtime suspend gets enabled, the additional patch is needed.
I’ll remember to enable runtime pm next time.
Thanks again.
Kai-Heng
>
> Thanks
>
> Matthias
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-12-16 3:05 ` Matthias Kaehlcke
2017-12-18 5:16 ` Kai Heng Feng
@ 2017-12-18 11:43 ` Greg Kroah-Hartman
2017-12-18 18:13 ` Brian Norris
1 sibling, 1 reply; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-18 11:43 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: linux-kernel, stable, Leif Liddy, Marcel Holtmann, Kai Heng Feng,
Brian Norris, Guenter Roeck
On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote:
> Hi,
>
> El Sun, Nov 19, 2017 at 03:43:50PM +0100 Greg Kroah-Hartman ha dit:
>
> > 4.13-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Leif Liddy <leif.linux@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@gmail.com>
> > Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> > Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > ---
> > drivers/bluetooth/btusb.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -3068,6 +3068,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
> >
> >
>
> On Chrome OS QCA Bluetooth stopped working after a merge from v4.4-stable:
>
> [ 124.789298] usb 2-1.1: reset full-speed USB device number 3 using ehci-platform
> [ 126.624274] Bluetooth: hci0 command 0x2005 tx timeout
> [ 128.672262] Bluetooth: hci0 command 0x200b tx timeout
> [ 130.720264] Bluetooth: hci0 command 0x200c tx timeout
>
> We identified the above patch as the culprit, in combination with USB
> autosuspend being enabled for the Bluetooth controller.
>
> We found that the following (recent) upstream patch fixes the issue on
> most devices (we are still investigating one case on a specific device):
>
> commit a0085f2510e8976614ad8f766b209448b385492f
> Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
> Date: Wed Aug 16 14:46:55 2017 -0700
>
> Bluetooth: btusb: driver to enable the usb-wakeup feature
>
> BT-Controller connected as platform non-root-hub device and
> usb-driver initialize such device with wakeup disabled,
> Ref. usb_new_device().
>
> At present wakeup-capability get enabled by hid-input device from usb
> function driver(e.g. BT HID device) at runtime. Again some functional
> driver does not set usb-wakeup capability(e.g LE HID device implement
> as HID-over-GATT), and can't wakeup the host on USB.
>
> Most of the device operation (such as mass storage) initiated from host
> (except HID) and USB wakeup aligned with host resume procedure. For BT
> device, usb-wakeup capability need to enable form btusc driver as a
> generic solution for multiple profile use case and required for USB remote
> wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature
> need to enable/disable with HCI interface up and down.
>
>
> stable branches are currently broken for BTUSB_QCA_ROME with USB
> autosuspend enabled, since the above patch is not included (I only
> checked v4.4 and v4.9), so we probably want to integrate it.
Now queued up, thanks for letting me know.
greg k-h
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-12-18 11:43 ` Greg Kroah-Hartman
@ 2017-12-18 18:13 ` Brian Norris
2017-12-19 4:28 ` Kai Heng Feng
0 siblings, 1 reply; 45+ messages in thread
From: Brian Norris @ 2017-12-18 18:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Matthias Kaehlcke, linux-kernel, stable, Leif Liddy,
Marcel Holtmann, Kai Heng Feng, Guenter Roeck
Hi Greg,
On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote:
> > We identified the above patch as the culprit, in combination with USB
> > autosuspend being enabled for the Bluetooth controller.
> >
> > We found that the following (recent) upstream patch fixes the issue on
> > most devices (we are still investigating one case on a specific device):
A key word to highlight here is "most". I have at least one device that
is consistently having problems even with both patches included; the
only way things work reliably so far is to simply revert the $subject
patch in 4.4.x.
I'll try to investigate further, since this result is a bit confusing
still. If there's a real problem with the patch (and I suspect there
might be), it probably shouldn't be in mainline either...
> > commit a0085f2510e8976614ad8f766b209448b385492f
> > Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
> > Date: Wed Aug 16 14:46:55 2017 -0700
> >
> > Bluetooth: btusb: driver to enable the usb-wakeup feature
[...]
> > stable branches are currently broken for BTUSB_QCA_ROME with USB
> > autosuspend enabled, since the above patch is not included (I only
> > checked v4.4 and v4.9), so we probably want to integrate it.
>
> Now queued up, thanks for letting me know.
I think you have almost as much information as I do at this point, and
I'll try to reply back here if I figure out anything more, so I'll leave
you to your decisions. But I would personally revert, not backport more
patches.
Among the reasons:
(a) I have at least one device that does not work better with both
patches [1]
(b) So far, I haven't seen any explanation why commit a0085f2510e8
should be a dependency for $subject patch; the closest I can imagine
would be that commit a0085f2510e8 could effectively neutralize
$subject patch -- if the device is marked as a wakeup source, then
it will never try to RESET on resume -- but that's still a fuzzy
signal; just because it's marked a wakeup source sometimes doesn't
mean it always will be. We can disable it in user space too.
(c) Isn't it safer to revert than to backport more? You're delving into
feature-land, not bugfix-land...
Brian
[1] Before you ask: this particular device is not quite fully supported
on upstream yet, though its sibling devices are. With a bit of effort, I
might be able to test a clean upstream. At the moment, I'm using our
Chrom{e,ium}OS 4.4 kernel, where we regularly merge in -stable updates.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-12-18 18:13 ` Brian Norris
@ 2017-12-19 4:28 ` Kai Heng Feng
2017-12-19 23:11 ` Brian Norris
0 siblings, 1 reply; 45+ messages in thread
From: Kai Heng Feng @ 2017-12-19 4:28 UTC (permalink / raw)
To: Brian Norris
Cc: Greg Kroah-Hartman, Matthias Kaehlcke, linux-kernel, stable,
Leif Liddy, Marcel Holtmann, Guenter Roeck
Hi Brian,
> On 19 Dec 2017, at 2:13 AM, Brian Norris <briannorris@chromium.org> wrote:
>
> Hi Greg,
>
> On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote:
>> On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote:
>>> We identified the above patch as the culprit, in combination with USB
>>> autosuspend being enabled for the Bluetooth controller.
>>>
>>> We found that the following (recent) upstream patch fixes the issue on
>>> most devices (we are still investigating one case on a specific device):
>
> A key word to highlight here is "most". I have at least one device that
> is consistently having problems even with both patches included; the
> only way things work reliably so far is to simply revert the $subject
> patch in 4.4.x.
The problem we have is that the QCA Rome Bluetooth stops working
after system S3. The reset resume quirk workaround the issue on both
mainline and 4.4.x (at least for me).
>
> I'll try to investigate further, since this result is a bit confusing
> still. If there's a real problem with the patch (and I suspect there
> might be), it probably shouldn't be in mainline either…
Do you have the same issue on mainline?
>
>>> commit a0085f2510e8976614ad8f766b209448b385492f
>>> Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
>>> Date: Wed Aug 16 14:46:55 2017 -0700
>>>
>>> Bluetooth: btusb: driver to enable the usb-wakeup feature
> [...]
>>> stable branches are currently broken for BTUSB_QCA_ROME with USB
>>> autosuspend enabled, since the above patch is not included (I only
>>> checked v4.4 and v4.9), so we probably want to integrate it.
>>
>> Now queued up, thanks for letting me know.
>
> I think you have almost as much information as I do at this point, and
> I'll try to reply back here if I figure out anything more, so I'll leave
> you to your decisions. But I would personally revert, not backport more
> patches.
>
> Among the reasons:
> (a) I have at least one device that does not work better with both
> patches [1]
> (b) So far, I haven't seen any explanation why commit a0085f2510e8
> should be a dependency for $subject patch; the closest I can imagine
> would be that commit a0085f2510e8 could effectively neutralize
> $subject patch -- if the device is marked as a wakeup source, then
> it will never try to RESET on resume -- but that's still a fuzzy
> signal; just because it's marked a wakeup source sometimes doesn't
> mean it always will be. We can disable it in user space too.
Hi Leif,
Can you try if a0085f2510e8 breaks your $subject commit?
If it’s a yes, then what Brian suggests is correct.
Also, can you share the output of "usb-device” for your btusb device?
> (c) Isn't it safer to revert than to backport more? You're delving into
> feature-land, not bugfix-land…
Sounds reasonable.
We’ll need more information from Leif if we need to do ID-specific quirks.
Kai-Heng
> Brian
>
> [1] Before you ask: this particular device is not quite fully supported
> on upstream yet, though its sibling devices are. With a bit of effort, I
> might be able to test a clean upstream. At the moment, I'm using our
> Chrom{e,ium}OS 4.4 kernel, where we regularly merge in -stable updates.
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-12-19 4:28 ` Kai Heng Feng
@ 2017-12-19 23:11 ` Brian Norris
2017-12-20 8:42 ` Kai Heng Feng
0 siblings, 1 reply; 45+ messages in thread
From: Brian Norris @ 2017-12-19 23:11 UTC (permalink / raw)
To: Kai Heng Feng
Cc: Greg Kroah-Hartman, Matthias Kaehlcke, linux-kernel, stable,
Leif Liddy, Marcel Holtmann, Guenter Roeck
Hi Kai,
On Tue, Dec 19, 2017 at 12:28:17PM +0800, Kai Heng Feng wrote:
> > On 19 Dec 2017, at 2:13 AM, Brian Norris <briannorris@chromium.org> wrote:
> > On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote:
> >> On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote:
> >>> We identified the above patch as the culprit, in combination with USB
> >>> autosuspend being enabled for the Bluetooth controller.
> >>>
> >>> We found that the following (recent) upstream patch fixes the issue on
> >>> most devices (we are still investigating one case on a specific device):
> >
> > A key word to highlight here is "most". I have at least one device that
> > is consistently having problems even with both patches included; the
> > only way things work reliably so far is to simply revert the $subject
> > patch in 4.4.x.
>
> The problem we have is that the QCA Rome Bluetooth stops working
> after system S3. The reset resume quirk workaround the issue on both
> mainline and 4.4.x (at least for me).
Understood. But that's not the case for all systems, and on some, you're
regressing functionality.
Many systems keep power enabled for system suspend, and so that "fix" is
not necessary for them. It's also not very precise, because it seems to
act in many cases where it need not -- for one, it takes effect on *all*
resume attempts, even resuming from autosuspend. I really doubt your
system is losing USB power in S0 + USB autosuspend?
So, if you really need this patch for some systems, it seems like it
should be much better targeted. You're currently adding a lot of
unnecessary overhead and fragility.
> > I'll try to investigate further, since this result is a bit confusing
> > still. If there's a real problem with the patch (and I suspect there
> > might be), it probably shouldn't be in mainline either…
>
> Do you have the same issue on mainline?
Refer to my note [1] :)
But because you asked, I did the work necessary to boot mainline on this
system, and in fact, I see the same problem. I think that's enough
reason to revert your patch in all branches (upstream, and any -stable
branch that already took it).
To be clear, here's the kernel logs on 4.15-rc4+, where the 55-second
mark is around where I try to power on and scan for BT devices (power-on
and scan both fail):
[ 2.323475] usb 3-1: new full-speed USB device number 2 using ohci-platform
...
[ 2.731719] usb 3-1: New USB device found, idVendor=0cf3, idProduct=e300
...
[ 2.867870] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
...(udev doesn't run until here)...
[ 35.733139] usbcore: registered new interface driver btusb
[ 35.740912] Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000302.bin
[ 35.749216] Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
...
[ 35.816104] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
...
[ 55.073503] usb 3-1: reset full-speed USB device number 2 using ohci-platform
...
[ 57.772513] Bluetooth: hci0: urb 00000000ec39086b failed to resubmit (113)
[ 57.780217] Bluetooth: hci0: urb 0000000066228fda failed to resubmit (113)
Whereas reverting the $subject patch yields no reset and URB failure;
Bluetooth seems to work fine.
> >>> commit a0085f2510e8976614ad8f766b209448b385492f
> >>> Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
> >>> Date: Wed Aug 16 14:46:55 2017 -0700
> >>>
> >>> Bluetooth: btusb: driver to enable the usb-wakeup feature
> > [...]
> >>> stable branches are currently broken for BTUSB_QCA_ROME with USB
> >>> autosuspend enabled, since the above patch is not included (I only
> >>> checked v4.4 and v4.9), so we probably want to integrate it.
> >>
> >> Now queued up, thanks for letting me know.
> >
> > I think you have almost as much information as I do at this point, and
> > I'll try to reply back here if I figure out anything more, so I'll leave
> > you to your decisions. But I would personally revert, not backport more
> > patches.
> >
> > Among the reasons:
> > (a) I have at least one device that does not work better with both
> > patches [1]
> > (b) So far, I haven't seen any explanation why commit a0085f2510e8
> > should be a dependency for $subject patch; the closest I can imagine
> > would be that commit a0085f2510e8 could effectively neutralize
> > $subject patch -- if the device is marked as a wakeup source, then
> > it will never try to RESET on resume -- but that's still a fuzzy
> > signal; just because it's marked a wakeup source sometimes doesn't
> > mean it always will be. We can disable it in user space too.
>
> Hi Leif,
>
> Can you try if a0085f2510e8 breaks your $subject commit?
> If it’s a yes, then what Brian suggests is correct.
>
> Also, can you share the output of "usb-device” for your btusb device?
FWIW, here's mine:
T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e300 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
This is an integrated Wifi+BT QCA6174A-5 M.2 module.
> > (c) Isn't it safer to revert than to backport more? You're delving into
> > feature-land, not bugfix-land…
>
> Sounds reasonable.
Shall I post a proper revert for mainline, with Fixes tags and CC
stable? Or did one of you want to do that?
> We’ll need more information from Leif if we need to do ID-specific quirks.
As I see it, this probably isn't just an ID-specific thing; this patch
looks bad for its intended purpose, per my comments above (it's
overkill, for one). I think there are many factors involved here, and it
needs more study than "I just booted, suspended/resumed once, and it
worked better."
Among the things to consider:
* How do we determine the likelihood that the device gets powered off in
S3? The device_may_wakeup() check can be influenced (among other
things) by user space policy, so that doesn't really look right to me.
(ID-based checks might help a little, since you can probably
differentiate chips that are likely used on discrete/removable USB
parts, rather than internal chips?)
* The ordering: right now, you're enabling "reset on resume" at probe
time, but QCA ROME devices only load their firmware in btusb_open().
This gives a window of time in which you're adding weird reset
behavior while the device may be running its ROM firmware, not the
patched firmware loaded from /lib/firmware/. That might be one reason
things don't work out so well?
I also suspect that might be one reason that Matthias sometimes saw
the problem disappear on his devices, where I didn't. I have my device
configured to cold reset the BT device on every reboot, whereas his
isn't; it might retain the FW in the BT device's RAM across reboot.
So my behavior was more deterministic :)
* The behavior here is affected by USB autosuspend, not just S3. I
mentioned this above, but more specifically, ChromeOS has udev rules
like this, to enable autosuspend on various sorts of devices
(including bluetooth controllers + BT HID devices):
<udev rule snippet>
ATTR{idVendor}=="0cf3", ATTR{idProduct}=="e300", GOTO="autosuspend_enable"
...
# Enable autosuspend
LABEL="autosuspend_enable"
TEST=="power/control", ATTR{power/control}="auto", GOTO="autosuspend_end"
LABEL="autosuspend_end"
</udev rule snippet>
I suspect some desktop systems might not have the same policies, so
you're not testing autosuspend in the same way I am?
Brian
> Kai-Heng
>
> > Brian
> >
> > [1] Before you ask: this particular device is not quite fully supported
> > on upstream yet, though its sibling devices are. With a bit of effort, I
> > might be able to test a clean upstream. At the moment, I'm using our
> > Chrom{e,ium}OS 4.4 kernel, where we regularly merge in -stable updates.
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume
2017-12-19 23:11 ` Brian Norris
@ 2017-12-20 8:42 ` Kai Heng Feng
0 siblings, 0 replies; 45+ messages in thread
From: Kai Heng Feng @ 2017-12-20 8:42 UTC (permalink / raw)
To: Brian Norris
Cc: Greg Kroah-Hartman, Matthias Kaehlcke, LKML, stable, Leif Liddy,
Marcel Holtmann, Guenter Roeck
> On 20 Dec 2017, at 7:11 AM, Brian Norris <briannorris@chromium.org> wrote:
>
> Hi Kai,
>
> On Tue, Dec 19, 2017 at 12:28:17PM +0800, Kai Heng Feng wrote:
>>> On 19 Dec 2017, at 2:13 AM, Brian Norris <briannorris@chromium.org> wrote:
>>> On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote:
>>>> On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote:
>>>>> We identified the above patch as the culprit, in combination with USB
>>>>> autosuspend being enabled for the Bluetooth controller.
>>>>>
>>>>> We found that the following (recent) upstream patch fixes the issue on
>>>>> most devices (we are still investigating one case on a specific device):
>>>
>>> A key word to highlight here is "most". I have at least one device that
>>> is consistently having problems even with both patches included; the
>>> only way things work reliably so far is to simply revert the $subject
>>> patch in 4.4.x.
>>
>> The problem we have is that the QCA Rome Bluetooth stops working
>> after system S3. The reset resume quirk workaround the issue on both
>> mainline and 4.4.x (at least for me).
>
> Understood. But that's not the case for all systems, and on some, you're
> regressing functionality.
Yes. So reverting the commit is a reasonable path we should take.
>
> Many systems keep power enabled for system suspend, and so that "fix" is
> not necessary for them. It's also not very precise, because it seems to
> act in many cases where it need not -- for one, it takes effect on *all*
> resume attempts, even resuming from autosuspend. I really doubt your
> system is losing USB power in S0 + USB autosuspend?
No, USB power is on. Not seeing my XHCI gets put to D3cold.
>
> So, if you really need this patch for some systems, it seems like it
> should be much better targeted. You're currently adding a lot of
> unnecessary overhead and fragility.
You are right. Applying this unconditionally to all QCA Rome may be
overkill.
>
>>> I'll try to investigate further, since this result is a bit confusing
>>> still. If there's a real problem with the patch (and I suspect there
>>> might be), it probably shouldn't be in mainline either…
>>
>> Do you have the same issue on mainline?
>
> Refer to my note [1] :)
>
> But because you asked, I did the work necessary to boot mainline on this
> system, and in fact, I see the same problem. I think that's enough
> reason to revert your patch in all branches (upstream, and any -stable
> branch that already took it).
>
> To be clear, here's the kernel logs on 4.15-rc4+, where the 55-second
> mark is around where I try to power on and scan for BT devices (power-on
> and scan both fail):
>
> [ 2.323475] usb 3-1: new full-speed USB device number 2 using ohci-platform
> ...
> [ 2.731719] usb 3-1: New USB device found, idVendor=0cf3, idProduct=e300
> ...
> [ 2.867870] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> ...(udev doesn't run until here)...
> [ 35.733139] usbcore: registered new interface driver btusb
> [ 35.740912] Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000302.bin
> [ 35.749216] Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
> ...
> [ 35.816104] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
> ...
> [ 55.073503] usb 3-1: reset full-speed USB device number 2 using ohci-platform
> ...
> [ 57.772513] Bluetooth: hci0: urb 00000000ec39086b failed to resubmit (113)
> [ 57.780217] Bluetooth: hci0: urb 0000000066228fda failed to resubmit (113)
>
> Whereas reverting the $subject patch yields no reset and URB failure;
> Bluetooth seems to work fine.
Thanks for your testing on mainline!
>
>>>>> commit a0085f2510e8976614ad8f766b209448b385492f
>>>>> Author: Sukumar Ghorai <sukumar.ghorai@intel.com>
>>>>> Date: Wed Aug 16 14:46:55 2017 -0700
>>>>>
>>>>> Bluetooth: btusb: driver to enable the usb-wakeup feature
>>> [...]
>>>>> stable branches are currently broken for BTUSB_QCA_ROME with USB
>>>>> autosuspend enabled, since the above patch is not included (I only
>>>>> checked v4.4 and v4.9), so we probably want to integrate it.
>>>>
>>>> Now queued up, thanks for letting me know.
>>>
>>> I think you have almost as much information as I do at this point, and
>>> I'll try to reply back here if I figure out anything more, so I'll leave
>>> you to your decisions. But I would personally revert, not backport more
>>> patches.
>>>
>>> Among the reasons:
>>> (a) I have at least one device that does not work better with both
>>> patches [1]
>>> (b) So far, I haven't seen any explanation why commit a0085f2510e8
>>> should be a dependency for $subject patch; the closest I can imagine
>>> would be that commit a0085f2510e8 could effectively neutralize
>>> $subject patch -- if the device is marked as a wakeup source, then
>>> it will never try to RESET on resume -- but that's still a fuzzy
>>> signal; just because it's marked a wakeup source sometimes doesn't
>>> mean it always will be. We can disable it in user space too.
>>
>> Hi Leif,
>>
>> Can you try if a0085f2510e8 breaks your $subject commit?
>> If it’s a yes, then what Brian suggests is correct.
>>
>> Also, can you share the output of "usb-device” for your btusb device?
>
> FWIW, here's mine:
>
> T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0cf3 ProdID=e300 Rev=00.01
> C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
>
> This is an integrated Wifi+BT QCA6174A-5 M.2 module.
Thanks for the info. I found the same BT on a Killer Wireless, I’ll do
some testing on it.
>
>>> (c) Isn't it safer to revert than to backport more? You're delving into
>>> feature-land, not bugfix-land…
>>
>> Sounds reasonable.
>
> Shall I post a proper revert for mainline, with Fixes tags and CC
> stable? Or did one of you want to do that?
Let me clean my own mess ;)
>
>> We’ll need more information from Leif if we need to do ID-specific quirks.
>
> As I see it, this probably isn't just an ID-specific thing; this patch
> looks bad for its intended purpose, per my comments above (it's
> overkill, for one). I think there are many factors involved here, and it
> needs more study than "I just booted, suspended/resumed once, and it
> worked better."
>
> Among the things to consider:
> * How do we determine the likelihood that the device gets powered off in
> S3? The device_may_wakeup() check can be influenced (among other
> things) by user space policy, so that doesn't really look right to me.
> (ID-based checks might help a little, since you can probably
> differentiate chips that are likely used on discrete/removable USB
> parts, rather than internal chips?)
Actually, I think we can’t know for sure. From my own experience, it’s
pretty ODM specific. Some external chips keep its power under S3.
> * The ordering: right now, you're enabling "reset on resume" at probe
> time, but QCA ROME devices only load their firmware in btusb_open().
> This gives a window of time in which you're adding weird reset
> behavior while the device may be running its ROM firmware, not the
> patched firmware loaded from /lib/firmware/. That might be one reason
> things don't work out so well?
You are right, the reset on resume should be used when USB probing,
instead of in the middle of btusb_open().
> I also suspect that might be one reason that Matthias sometimes saw
> the problem disappear on his devices, where I didn't. I have my device
> configured to cold reset the BT device on every reboot, whereas his
> isn't; it might retain the FW in the BT device's RAM across reboot.
> So my behavior was more deterministic :)
> * The behavior here is affected by USB autosuspend, not just S3. I
> mentioned this above, but more specifically, ChromeOS has udev rules
> like this, to enable autosuspend on various sorts of devices
> (including bluetooth controllers + BT HID devices):
>
> <udev rule snippet>
> ATTR{idVendor}=="0cf3", ATTR{idProduct}=="e300", GOTO="autosuspend_enable"
> ...
> # Enable autosuspend
> LABEL="autosuspend_enable"
> TEST=="power/control", ATTR{power/control}="auto", GOTO="autosuspend_end"
>
> LABEL="autosuspend_end"
> </udev rule snippet>
>
> I suspect some desktop systems might not have the same policies, so
> you're not testing autosuspend in the same way I am?
Actually it’s same from kernel’s perspective. I use TLP, it does the same
thing to the power/control knob.
Kai-Heng
>
> Brian
>
>> Kai-Heng
>>
>>> Brian
>>>
>>> [1] Before you ask: this particular device is not quite fully supported
>>> on upstream yet, though its sibling devices are. With a bit of effort, I
>>> might be able to test a clean upstream. At the moment, I'm using our
>>> Chrom{e,ium}OS 4.4 kernel, where we regularly merge in -stable updates.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH 4.13 04/28] crypto: dh - Fix double free of ctx->p
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 05/28] crypto: dh - Dont permit p to be 0 Greg Kroah-Hartman
` (24 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, Tudor Ambarus,
Herbert Xu
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 12d41a023efb01b846457ccdbbcbe2b65a87d530 upstream.
When setting the secret with the software Diffie-Hellman implementation,
if allocating 'g' failed (e.g. if it was longer than
MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and
once later when the crypto_kpp tfm was destroyed.
Fix it by using dh_free_ctx() (renamed to dh_clear_ctx()) in the error
paths, as that correctly sets the pointers to NULL.
KASAN report:
MPI: mpi too large (32760 bits)
==================================================================
BUG: KASAN: use-after-free in mpi_free+0x131/0x170
Read of size 4 at addr ffff88006c7cdf90 by task reproduce_doubl/367
CPU: 1 PID: 367 Comm: reproduce_doubl Not tainted 4.14.0-rc7-00040-g05298abde6fe #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
dump_stack+0xb3/0x10b
? mpi_free+0x131/0x170
print_address_description+0x79/0x2a0
? mpi_free+0x131/0x170
kasan_report+0x236/0x340
? akcipher_register_instance+0x90/0x90
__asan_report_load4_noabort+0x14/0x20
mpi_free+0x131/0x170
? akcipher_register_instance+0x90/0x90
dh_exit_tfm+0x3d/0x140
crypto_kpp_exit_tfm+0x52/0x70
crypto_destroy_tfm+0xb3/0x250
__keyctl_dh_compute+0x640/0xe90
? kasan_slab_free+0x12f/0x180
? dh_data_from_key+0x240/0x240
? key_create_or_update+0x1ee/0xb20
? key_instantiate_and_link+0x440/0x440
? lock_contended+0xee0/0xee0
? kfree+0xcf/0x210
? SyS_add_key+0x268/0x340
keyctl_dh_compute+0xb3/0xf1
? __keyctl_dh_compute+0xe90/0xe90
? SyS_add_key+0x26d/0x340
? entry_SYSCALL_64_fastpath+0x5/0xbe
? trace_hardirqs_on_caller+0x3f4/0x560
SyS_keyctl+0x72/0x2c0
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x43ccf9
RSP: 002b:00007ffeeec96158 EFLAGS: 00000246 ORIG_RAX: 00000000000000fa
RAX: ffffffffffffffda RBX: 000000000248b9b9 RCX: 000000000043ccf9
RDX: 00007ffeeec96170 RSI: 00007ffeeec96160 RDI: 0000000000000017
RBP: 0000000000000046 R08: 0000000000000000 R09: 0248b9b9143dc936
R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000409670 R14: 0000000000409700 R15: 0000000000000000
Allocated by task 367:
save_stack_trace+0x16/0x20
kasan_kmalloc+0xeb/0x180
kmem_cache_alloc_trace+0x114/0x300
mpi_alloc+0x4b/0x230
mpi_read_raw_data+0xbe/0x360
dh_set_secret+0x1dc/0x460
__keyctl_dh_compute+0x623/0xe90
keyctl_dh_compute+0xb3/0xf1
SyS_keyctl+0x72/0x2c0
entry_SYSCALL_64_fastpath+0x1f/0xbe
Freed by task 367:
save_stack_trace+0x16/0x20
kasan_slab_free+0xab/0x180
kfree+0xb5/0x210
mpi_free+0xcb/0x170
dh_set_secret+0x2d7/0x460
__keyctl_dh_compute+0x623/0xe90
keyctl_dh_compute+0xb3/0xf1
SyS_keyctl+0x72/0x2c0
entry_SYSCALL_64_fastpath+0x1f/0xbe
Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/dh.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
--- a/crypto/dh.c
+++ b/crypto/dh.c
@@ -21,19 +21,12 @@ struct dh_ctx {
MPI xa;
};
-static inline void dh_clear_params(struct dh_ctx *ctx)
+static void dh_clear_ctx(struct dh_ctx *ctx)
{
mpi_free(ctx->p);
mpi_free(ctx->g);
- ctx->p = NULL;
- ctx->g = NULL;
-}
-
-static void dh_free_ctx(struct dh_ctx *ctx)
-{
- dh_clear_params(ctx);
mpi_free(ctx->xa);
- ctx->xa = NULL;
+ memset(ctx, 0, sizeof(*ctx));
}
/*
@@ -71,10 +64,8 @@ static int dh_set_params(struct dh_ctx *
return -EINVAL;
ctx->g = mpi_read_raw_data(params->g, params->g_size);
- if (!ctx->g) {
- mpi_free(ctx->p);
+ if (!ctx->g)
return -EINVAL;
- }
return 0;
}
@@ -86,21 +77,23 @@ static int dh_set_secret(struct crypto_k
struct dh params;
/* Free the old MPI key if any */
- dh_free_ctx(ctx);
+ dh_clear_ctx(ctx);
if (crypto_dh_decode_key(buf, len, ¶ms) < 0)
- return -EINVAL;
+ goto err_clear_ctx;
if (dh_set_params(ctx, ¶ms) < 0)
- return -EINVAL;
+ goto err_clear_ctx;
ctx->xa = mpi_read_raw_data(params.key, params.key_size);
- if (!ctx->xa) {
- dh_clear_params(ctx);
- return -EINVAL;
- }
+ if (!ctx->xa)
+ goto err_clear_ctx;
return 0;
+
+err_clear_ctx:
+ dh_clear_ctx(ctx);
+ return -EINVAL;
}
static int dh_compute_value(struct kpp_request *req)
@@ -158,7 +151,7 @@ static void dh_exit_tfm(struct crypto_kp
{
struct dh_ctx *ctx = dh_get_ctx(tfm);
- dh_free_ctx(ctx);
+ dh_clear_ctx(ctx);
}
static struct kpp_alg dh = {
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 05/28] crypto: dh - Dont permit p to be 0
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 04/28] crypto: dh - Fix double free of ctx->p Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 06/28] crypto: dh - Dont permit key or g size longer than p Greg Kroah-Hartman
` (23 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tudor Ambarus, Eric Biggers,
Herbert Xu
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 199512b1234f09e44d592153ec82b44212b2f0c4 upstream.
If 'p' is 0 for the software Diffie-Hellman implementation, then
dh_max_size() returns 0. In the case of KEYCTL_DH_COMPUTE, this causes
ZERO_SIZE_PTR to be passed to sg_init_one(), which with
CONFIG_DEBUG_SG=y triggers the 'BUG_ON(!virt_addr_valid(buf));' in
sg_set_buf().
Fix this by making crypto_dh_decode_key() reject 0 for 'p'. p=0 makes
no sense for any DH implementation because 'p' is supposed to be a prime
number. Moreover, 'mod 0' is not mathematically defined.
Bug report:
kernel BUG at ./include/linux/scatterlist.h:140!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 27112 Comm: syz-executor2 Not tainted 4.14.0-rc7-00010-gf5dbb5d0ce32-dirty #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014
task: ffff88006caac0c0 task.stack: ffff88006c7c8000
RIP: 0010:sg_set_buf include/linux/scatterlist.h:140 [inline]
RIP: 0010:sg_init_one+0x1b3/0x240 lib/scatterlist.c:156
RSP: 0018:ffff88006c7cfb08 EFLAGS: 00010216
RAX: 0000000000010000 RBX: ffff88006c7cfe30 RCX: 00000000000064ee
RDX: ffffffff81cf64c3 RSI: ffffc90000d72000 RDI: ffffffff92e937e0
RBP: ffff88006c7cfb30 R08: ffffed000d8f9fab R09: ffff88006c7cfd30
R10: 0000000000000005 R11: ffffed000d8f9faa R12: ffff88006c7cfd30
R13: 0000000000000000 R14: 0000000000000010 R15: ffff88006c7cfc50
FS: 00007fce190fa700(0000) GS:ffff88003ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffc6b33db8 CR3: 000000003cf64000 CR4: 00000000000006f0
Call Trace:
__keyctl_dh_compute+0xa95/0x19b0 security/keys/dh.c:360
keyctl_dh_compute+0xac/0x100 security/keys/dh.c:434
SYSC_keyctl security/keys/keyctl.c:1745 [inline]
SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1641
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4585c9
RSP: 002b:00007fce190f9bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000fa
RAX: ffffffffffffffda RBX: 0000000000738020 RCX: 00000000004585c9
RDX: 000000002000d000 RSI: 0000000020000ff4 RDI: 0000000000000017
RBP: 0000000000000046 R08: 0000000020008000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff6e610cde
R13: 00007fff6e610cdf R14: 00007fce190fa700 R15: 0000000000000000
Code: 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 33 5b 45 89 6c 24 14 41 5c 41 5d 41 5e 41 5f 5d c3 e8 fd 8f 68 ff <0f> 0b e8 f6 8f 68 ff 0f 0b e8 ef 8f 68 ff 0f 0b e8 e8 8f 68 ff 20
RIP: sg_set_buf include/linux/scatterlist.h:140 [inline] RSP: ffff88006c7cfb08
RIP: sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: ffff88006c7cfb08
Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation")
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/dh_helper.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -90,6 +90,14 @@ int crypto_dh_decode_key(const char *buf
params->p = (void *)(ptr + params->key_size);
params->g = (void *)(ptr + params->key_size + params->p_size);
+ /*
+ * Don't permit 'p' to be 0. It's not a prime number, and it's subject
+ * to corner cases such as 'mod 0' being undefined or
+ * crypto_kpp_maxsize() returning 0.
+ */
+ if (memchr_inv(params->p, 0, params->p_size) == NULL)
+ return -EINVAL;
+
return 0;
}
EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 06/28] crypto: dh - Dont permit key or g size longer than p
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 05/28] crypto: dh - Dont permit p to be 0 Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message Greg Kroah-Hartman
` (22 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, Tudor Ambarus,
Herbert Xu
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit ccd9888f14a8019c0bbdeeae758aba1f58693712 upstream.
The "qat-dh" DH implementation assumes that 'key' and 'g' can be copied
into a buffer with size 'p_size'. However it was never checked that
that was actually the case, which most likely allowed users to cause a
buffer underflow via KEYCTL_DH_COMPUTE.
Fix this by updating crypto_dh_decode_key() to verify this precondition
for all DH implementations.
Fixes: c9839143ebbf ("crypto: qat - Add DH support")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
crypto/dh_helper.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -83,6 +83,14 @@ int crypto_dh_decode_key(const char *buf
if (secret.len != crypto_dh_key_len(params))
return -EINVAL;
+ /*
+ * Don't permit the buffer for 'key' or 'g' to be larger than 'p', since
+ * some drivers assume otherwise.
+ */
+ if (params->key_size > params->p_size ||
+ params->g_size > params->p_size)
+ return -EINVAL;
+
/* Don't allocate memory. Set pointers to data within
* the given buffer
*/
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 06/28] crypto: dh - Dont permit key or g size longer than p Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-21 7:51 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 08/28] USB: early: Use new USB product ID and strings for DbC device Greg Kroah-Hartman
` (21 subsequent siblings)
28 siblings, 1 reply; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Raveendra Padasalagi, Anup Patel,
Scott Branden, Herbert Xu
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
commit f0e2ce58f853634d7ad1a418a49bd5fbd556227c upstream.
Add support to explicity ACK mailbox message
because after sending message we can know
the send status via error attribute of brcm_message.
This is needed to support "txdone_ack" supported in
mailbox controller driver.
Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
Reviewed-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/bcm/cipher.c | 101 ++++++++++++++++++++------------------------
1 file changed, 46 insertions(+), 55 deletions(-)
--- a/drivers/crypto/bcm/cipher.c
+++ b/drivers/crypto/bcm/cipher.c
@@ -258,6 +258,44 @@ spu_ablkcipher_tx_sg_create(struct brcm_
return 0;
}
+static int mailbox_send_message(struct brcm_message *mssg, u32 flags,
+ u8 chan_idx)
+{
+ int err;
+ int retry_cnt = 0;
+ struct device *dev = &(iproc_priv.pdev->dev);
+
+ err = mbox_send_message(iproc_priv.mbox[chan_idx], mssg);
+ if (flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
+ while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
+ /*
+ * Mailbox queue is full. Since MAY_SLEEP is set, assume
+ * not in atomic context and we can wait and try again.
+ */
+ retry_cnt++;
+ usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
+ err = mbox_send_message(iproc_priv.mbox[chan_idx],
+ mssg);
+ atomic_inc(&iproc_priv.mb_no_spc);
+ }
+ }
+ if (err < 0) {
+ atomic_inc(&iproc_priv.mb_send_fail);
+ return err;
+ }
+
+ /* Check error returned by mailbox controller */
+ err = mssg->error;
+ if (unlikely(err < 0)) {
+ dev_err(dev, "message error %d", err);
+ /* Signal txdone for mailbox channel */
+ }
+
+ /* Signal txdone for mailbox channel */
+ mbox_client_txdone(iproc_priv.mbox[chan_idx], err);
+ return err;
+}
+
/**
* handle_ablkcipher_req() - Submit as much of a block cipher request as fits in
* a single SPU request message, starting at the current position in the request
@@ -295,7 +333,6 @@ static int handle_ablkcipher_req(struct
u32 pad_len; /* total length of all padding */
bool update_key = false;
struct brcm_message *mssg; /* mailbox message */
- int retry_cnt = 0;
/* number of entries in src and dst sg in mailbox message. */
u8 rx_frag_num = 2; /* response header and STATUS */
@@ -464,24 +501,9 @@ static int handle_ablkcipher_req(struct
if (err)
return err;
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
- if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
- while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
- /*
- * Mailbox queue is full. Since MAY_SLEEP is set, assume
- * not in atomic context and we can wait and try again.
- */
- retry_cnt++;
- usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
- mssg);
- atomic_inc(&iproc_priv.mb_no_spc);
- }
- }
- if (unlikely(err < 0)) {
- atomic_inc(&iproc_priv.mb_send_fail);
+ err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
+ if (unlikely(err < 0))
return err;
- }
return -EINPROGRESS;
}
@@ -712,7 +734,6 @@ static int handle_ahash_req(struct iproc
u32 spu_hdr_len;
unsigned int digestsize;
u16 rem = 0;
- int retry_cnt = 0;
/*
* number of entries in src and dst sg. Always includes SPU msg header.
@@ -906,24 +927,10 @@ static int handle_ahash_req(struct iproc
if (err)
return err;
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
- if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
- while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
- /*
- * Mailbox queue is full. Since MAY_SLEEP is set, assume
- * not in atomic context and we can wait and try again.
- */
- retry_cnt++;
- usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
- mssg);
- atomic_inc(&iproc_priv.mb_no_spc);
- }
- }
- if (err < 0) {
- atomic_inc(&iproc_priv.mb_send_fail);
+ err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
+ if (unlikely(err < 0))
return err;
- }
+
return -EINPROGRESS;
}
@@ -1322,7 +1329,6 @@ static int handle_aead_req(struct iproc_
int assoc_nents = 0;
bool incl_icv = false;
unsigned int digestsize = ctx->digestsize;
- int retry_cnt = 0;
/* number of entries in src and dst sg. Always includes SPU msg header.
*/
@@ -1560,24 +1566,9 @@ static int handle_aead_req(struct iproc_
if (err)
return err;
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
- if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
- while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
- /*
- * Mailbox queue is full. Since MAY_SLEEP is set, assume
- * not in atomic context and we can wait and try again.
- */
- retry_cnt++;
- usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
- err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
- mssg);
- atomic_inc(&iproc_priv.mb_no_spc);
- }
- }
- if (err < 0) {
- atomic_inc(&iproc_priv.mb_send_fail);
+ err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
+ if (unlikely(err < 0))
return err;
- }
return -EINPROGRESS;
}
@@ -4534,7 +4525,7 @@ static int spu_mb_init(struct device *de
mcl->dev = dev;
mcl->tx_block = false;
mcl->tx_tout = 0;
- mcl->knows_txdone = false;
+ mcl->knows_txdone = true;
mcl->rx_callback = spu_rx_callback;
mcl->tx_done = NULL;
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message
2017-11-19 14:43 ` [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message Greg Kroah-Hartman
@ 2017-11-21 7:51 ` Greg Kroah-Hartman
2017-11-21 10:05 ` Raveendra Padasalagi
0 siblings, 1 reply; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-21 7:51 UTC (permalink / raw)
To: linux-kernel
Cc: stable, Raveendra Padasalagi, Anup Patel, Scott Branden,
Herbert Xu
Nope, this patch breaks the build as it relies on a previous patch that
is not in 4.13-stable, so I'm dropping it. If anyone wants it there,
well, it really feels like it shouldn't be included in a stable tree
anyway...
thanks,
greg k-h
On Sun, Nov 19, 2017 at 03:43:54PM +0100, Greg Kroah-Hartman wrote:
> 4.13-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
>
> commit f0e2ce58f853634d7ad1a418a49bd5fbd556227c upstream.
>
> Add support to explicity ACK mailbox message
> because after sending message we can know
> the send status via error attribute of brcm_message.
>
> This is needed to support "txdone_ack" supported in
> mailbox controller driver.
>
> Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
> Reviewed-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/crypto/bcm/cipher.c | 101 ++++++++++++++++++++------------------------
> 1 file changed, 46 insertions(+), 55 deletions(-)
>
> --- a/drivers/crypto/bcm/cipher.c
> +++ b/drivers/crypto/bcm/cipher.c
> @@ -258,6 +258,44 @@ spu_ablkcipher_tx_sg_create(struct brcm_
> return 0;
> }
>
> +static int mailbox_send_message(struct brcm_message *mssg, u32 flags,
> + u8 chan_idx)
> +{
> + int err;
> + int retry_cnt = 0;
> + struct device *dev = &(iproc_priv.pdev->dev);
> +
> + err = mbox_send_message(iproc_priv.mbox[chan_idx], mssg);
> + if (flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
> + while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
> + /*
> + * Mailbox queue is full. Since MAY_SLEEP is set, assume
> + * not in atomic context and we can wait and try again.
> + */
> + retry_cnt++;
> + usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
> + err = mbox_send_message(iproc_priv.mbox[chan_idx],
> + mssg);
> + atomic_inc(&iproc_priv.mb_no_spc);
> + }
> + }
> + if (err < 0) {
> + atomic_inc(&iproc_priv.mb_send_fail);
> + return err;
> + }
> +
> + /* Check error returned by mailbox controller */
> + err = mssg->error;
> + if (unlikely(err < 0)) {
> + dev_err(dev, "message error %d", err);
> + /* Signal txdone for mailbox channel */
> + }
> +
> + /* Signal txdone for mailbox channel */
> + mbox_client_txdone(iproc_priv.mbox[chan_idx], err);
> + return err;
> +}
> +
> /**
> * handle_ablkcipher_req() - Submit as much of a block cipher request as fits in
> * a single SPU request message, starting at the current position in the request
> @@ -295,7 +333,6 @@ static int handle_ablkcipher_req(struct
> u32 pad_len; /* total length of all padding */
> bool update_key = false;
> struct brcm_message *mssg; /* mailbox message */
> - int retry_cnt = 0;
>
> /* number of entries in src and dst sg in mailbox message. */
> u8 rx_frag_num = 2; /* response header and STATUS */
> @@ -464,24 +501,9 @@ static int handle_ablkcipher_req(struct
> if (err)
> return err;
>
> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
> - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
> - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
> - /*
> - * Mailbox queue is full. Since MAY_SLEEP is set, assume
> - * not in atomic context and we can wait and try again.
> - */
> - retry_cnt++;
> - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
> - mssg);
> - atomic_inc(&iproc_priv.mb_no_spc);
> - }
> - }
> - if (unlikely(err < 0)) {
> - atomic_inc(&iproc_priv.mb_send_fail);
> + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
> + if (unlikely(err < 0))
> return err;
> - }
>
> return -EINPROGRESS;
> }
> @@ -712,7 +734,6 @@ static int handle_ahash_req(struct iproc
> u32 spu_hdr_len;
> unsigned int digestsize;
> u16 rem = 0;
> - int retry_cnt = 0;
>
> /*
> * number of entries in src and dst sg. Always includes SPU msg header.
> @@ -906,24 +927,10 @@ static int handle_ahash_req(struct iproc
> if (err)
> return err;
>
> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
> - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
> - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
> - /*
> - * Mailbox queue is full. Since MAY_SLEEP is set, assume
> - * not in atomic context and we can wait and try again.
> - */
> - retry_cnt++;
> - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
> - mssg);
> - atomic_inc(&iproc_priv.mb_no_spc);
> - }
> - }
> - if (err < 0) {
> - atomic_inc(&iproc_priv.mb_send_fail);
> + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
> + if (unlikely(err < 0))
> return err;
> - }
> +
> return -EINPROGRESS;
> }
>
> @@ -1322,7 +1329,6 @@ static int handle_aead_req(struct iproc_
> int assoc_nents = 0;
> bool incl_icv = false;
> unsigned int digestsize = ctx->digestsize;
> - int retry_cnt = 0;
>
> /* number of entries in src and dst sg. Always includes SPU msg header.
> */
> @@ -1560,24 +1566,9 @@ static int handle_aead_req(struct iproc_
> if (err)
> return err;
>
> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
> - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
> - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
> - /*
> - * Mailbox queue is full. Since MAY_SLEEP is set, assume
> - * not in atomic context and we can wait and try again.
> - */
> - retry_cnt++;
> - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
> - mssg);
> - atomic_inc(&iproc_priv.mb_no_spc);
> - }
> - }
> - if (err < 0) {
> - atomic_inc(&iproc_priv.mb_send_fail);
> + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
> + if (unlikely(err < 0))
> return err;
> - }
>
> return -EINPROGRESS;
> }
> @@ -4534,7 +4525,7 @@ static int spu_mb_init(struct device *de
> mcl->dev = dev;
> mcl->tx_block = false;
> mcl->tx_tout = 0;
> - mcl->knows_txdone = false;
> + mcl->knows_txdone = true;
> mcl->rx_callback = spu_rx_callback;
> mcl->tx_done = NULL;
>
>
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message
2017-11-21 7:51 ` Greg Kroah-Hartman
@ 2017-11-21 10:05 ` Raveendra Padasalagi
0 siblings, 0 replies; 45+ messages in thread
From: Raveendra Padasalagi @ 2017-11-21 10:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Anup Patel, Scott Branden, Herbert Xu
Hi Greg,
Thanks for notifying the issue. This patch is supposed to be applied
on top of the below patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.14&id=9166c44358346c0a92b11fd4e24925efff791648
which is not present in stable, I missed to keep stable mailing list
in cc when this patch sent.
It's ok if you drop this patch for now in 4.13-stable.
For 4.14 stable release we need the current patch and the dependent
patch is already present in 4.14.
Regards,
Raveendra
On Tue, Nov 21, 2017 at 1:21 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> Nope, this patch breaks the build as it relies on a previous patch that
> is not in 4.13-stable, so I'm dropping it. If anyone wants it there,
> well, it really feels like it shouldn't be included in a stable tree
> anyway...
>
> thanks,
>
> greg k-h
>
> On Sun, Nov 19, 2017 at 03:43:54PM +0100, Greg Kroah-Hartman wrote:
>> 4.13-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: raveendra padasalagi <raveendra.padasalagi@broadcom.com>
>>
>> commit f0e2ce58f853634d7ad1a418a49bd5fbd556227c upstream.
>>
>> Add support to explicity ACK mailbox message
>> because after sending message we can know
>> the send status via error attribute of brcm_message.
>>
>> This is needed to support "txdone_ack" supported in
>> mailbox controller driver.
>>
>> Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
>> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
>> Reviewed-by: Anup Patel <anup.patel@broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> ---
>> drivers/crypto/bcm/cipher.c | 101 ++++++++++++++++++++------------------------
>> 1 file changed, 46 insertions(+), 55 deletions(-)
>>
>> --- a/drivers/crypto/bcm/cipher.c
>> +++ b/drivers/crypto/bcm/cipher.c
>> @@ -258,6 +258,44 @@ spu_ablkcipher_tx_sg_create(struct brcm_
>> return 0;
>> }
>>
>> +static int mailbox_send_message(struct brcm_message *mssg, u32 flags,
>> + u8 chan_idx)
>> +{
>> + int err;
>> + int retry_cnt = 0;
>> + struct device *dev = &(iproc_priv.pdev->dev);
>> +
>> + err = mbox_send_message(iproc_priv.mbox[chan_idx], mssg);
>> + if (flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
>> + while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
>> + /*
>> + * Mailbox queue is full. Since MAY_SLEEP is set, assume
>> + * not in atomic context and we can wait and try again.
>> + */
>> + retry_cnt++;
>> + usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
>> + err = mbox_send_message(iproc_priv.mbox[chan_idx],
>> + mssg);
>> + atomic_inc(&iproc_priv.mb_no_spc);
>> + }
>> + }
>> + if (err < 0) {
>> + atomic_inc(&iproc_priv.mb_send_fail);
>> + return err;
>> + }
>> +
>> + /* Check error returned by mailbox controller */
>> + err = mssg->error;
>> + if (unlikely(err < 0)) {
>> + dev_err(dev, "message error %d", err);
>> + /* Signal txdone for mailbox channel */
>> + }
>> +
>> + /* Signal txdone for mailbox channel */
>> + mbox_client_txdone(iproc_priv.mbox[chan_idx], err);
>> + return err;
>> +}
>> +
>> /**
>> * handle_ablkcipher_req() - Submit as much of a block cipher request as fits in
>> * a single SPU request message, starting at the current position in the request
>> @@ -295,7 +333,6 @@ static int handle_ablkcipher_req(struct
>> u32 pad_len; /* total length of all padding */
>> bool update_key = false;
>> struct brcm_message *mssg; /* mailbox message */
>> - int retry_cnt = 0;
>>
>> /* number of entries in src and dst sg in mailbox message. */
>> u8 rx_frag_num = 2; /* response header and STATUS */
>> @@ -464,24 +501,9 @@ static int handle_ablkcipher_req(struct
>> if (err)
>> return err;
>>
>> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
>> - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
>> - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
>> - /*
>> - * Mailbox queue is full. Since MAY_SLEEP is set, assume
>> - * not in atomic context and we can wait and try again.
>> - */
>> - retry_cnt++;
>> - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
>> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
>> - mssg);
>> - atomic_inc(&iproc_priv.mb_no_spc);
>> - }
>> - }
>> - if (unlikely(err < 0)) {
>> - atomic_inc(&iproc_priv.mb_send_fail);
>> + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
>> + if (unlikely(err < 0))
>> return err;
>> - }
>>
>> return -EINPROGRESS;
>> }
>> @@ -712,7 +734,6 @@ static int handle_ahash_req(struct iproc
>> u32 spu_hdr_len;
>> unsigned int digestsize;
>> u16 rem = 0;
>> - int retry_cnt = 0;
>>
>> /*
>> * number of entries in src and dst sg. Always includes SPU msg header.
>> @@ -906,24 +927,10 @@ static int handle_ahash_req(struct iproc
>> if (err)
>> return err;
>>
>> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
>> - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
>> - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
>> - /*
>> - * Mailbox queue is full. Since MAY_SLEEP is set, assume
>> - * not in atomic context and we can wait and try again.
>> - */
>> - retry_cnt++;
>> - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
>> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
>> - mssg);
>> - atomic_inc(&iproc_priv.mb_no_spc);
>> - }
>> - }
>> - if (err < 0) {
>> - atomic_inc(&iproc_priv.mb_send_fail);
>> + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
>> + if (unlikely(err < 0))
>> return err;
>> - }
>> +
>> return -EINPROGRESS;
>> }
>>
>> @@ -1322,7 +1329,6 @@ static int handle_aead_req(struct iproc_
>> int assoc_nents = 0;
>> bool incl_icv = false;
>> unsigned int digestsize = ctx->digestsize;
>> - int retry_cnt = 0;
>>
>> /* number of entries in src and dst sg. Always includes SPU msg header.
>> */
>> @@ -1560,24 +1566,9 @@ static int handle_aead_req(struct iproc_
>> if (err)
>> return err;
>>
>> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx], mssg);
>> - if (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) {
>> - while ((err == -ENOBUFS) && (retry_cnt < SPU_MB_RETRY_MAX)) {
>> - /*
>> - * Mailbox queue is full. Since MAY_SLEEP is set, assume
>> - * not in atomic context and we can wait and try again.
>> - */
>> - retry_cnt++;
>> - usleep_range(MBOX_SLEEP_MIN, MBOX_SLEEP_MAX);
>> - err = mbox_send_message(iproc_priv.mbox[rctx->chan_idx],
>> - mssg);
>> - atomic_inc(&iproc_priv.mb_no_spc);
>> - }
>> - }
>> - if (err < 0) {
>> - atomic_inc(&iproc_priv.mb_send_fail);
>> + err = mailbox_send_message(mssg, req->base.flags, rctx->chan_idx);
>> + if (unlikely(err < 0))
>> return err;
>> - }
>>
>> return -EINPROGRESS;
>> }
>> @@ -4534,7 +4525,7 @@ static int spu_mb_init(struct device *de
>> mcl->dev = dev;
>> mcl->tx_block = false;
>> mcl->tx_tout = 0;
>> - mcl->knows_txdone = false;
>> + mcl->knows_txdone = true;
>> mcl->rx_callback = spu_rx_callback;
>> mcl->tx_done = NULL;
>>
>>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH 4.13 08/28] USB: early: Use new USB product ID and strings for DbC device
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 07/28] crypto: brcm - Explicity ACK mailbox message Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 09/28] USB: usbfs: compute urb->actual_length for isochronous Greg Kroah-Hartman
` (20 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lu Baolu
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <baolu.lu@linux.intel.com>
commit c67678ec78eff9cf1e7e997fe6c37c9fcccfc5b8 upstream.
The DbC register set defines an interface for system software
to specify the vendor id and product id for the debug device.
These two values will be presented by the debug device in its
device descriptor idVendor and idProduct fields.
The current used product ID is a place holder. We now have a
valid one. The description strings are changed accordingly.
This patch should be back-ported to kernels as old as v4.12,
that contain the commit aeb9dd1de98c ("usb/early: Add driver
for xhci debug capability").
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/early/xhci-dbc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/usb/early/xhci-dbc.h
+++ b/drivers/usb/early/xhci-dbc.h
@@ -90,8 +90,8 @@ struct xdbc_context {
#define XDBC_INFO_CONTEXT_SIZE 48
#define XDBC_MAX_STRING_LENGTH 64
-#define XDBC_STRING_MANUFACTURER "Linux"
-#define XDBC_STRING_PRODUCT "Remote GDB"
+#define XDBC_STRING_MANUFACTURER "Linux Foundation"
+#define XDBC_STRING_PRODUCT "Linux USB GDB Target"
#define XDBC_STRING_SERIAL "0001"
struct xdbc_strings {
@@ -103,7 +103,7 @@ struct xdbc_strings {
#define XDBC_PROTOCOL 1 /* GNU Remote Debug Command Set */
#define XDBC_VENDOR_ID 0x1d6b /* Linux Foundation 0x1d6b */
-#define XDBC_PRODUCT_ID 0x0004 /* __le16 idProduct; device 0004 */
+#define XDBC_PRODUCT_ID 0x0011 /* __le16 idProduct; device 0011 */
#define XDBC_DEVICE_REV 0x0010 /* 0.10 */
/*
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 09/28] USB: usbfs: compute urb->actual_length for isochronous
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 08/28] USB: early: Use new USB product ID and strings for DbC device Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 10/28] USB: Add delay-init quirk for Corsair K70 LUX keyboards Greg Kroah-Hartman
` (19 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alan Stern, Minas Harutyunyan
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <stern@rowland.harvard.edu>
commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream.
The USB kerneldoc says that the actual_length field "is read in
non-iso completion functions", but the usbfs driver uses it for all
URB types in processcompl(). Since not all of the host controller
drivers set actual_length for isochronous URBs, programs using usbfs
with some host controllers don't work properly. For example, Minas
reports that a USB camera controlled by libusb doesn't work properly
with a dwc2 controller.
It doesn't seem worthwhile to change the HCDs and the documentation,
since the in-kernel USB class drivers evidently don't rely on
actual_length for isochronous transfers. The easiest solution is for
usbfs to calculate the actual_length value for itself, by adding up
the lengths of the individual packets in an isochronous transfer.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Reported-and-tested-by: wlf <wulf@rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/devio.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1833,6 +1833,18 @@ static int proc_unlinkurb(struct usb_dev
return 0;
}
+static void compute_isochronous_actual_length(struct urb *urb)
+{
+ unsigned int i;
+
+ if (urb->number_of_packets > 0) {
+ urb->actual_length = 0;
+ for (i = 0; i < urb->number_of_packets; i++)
+ urb->actual_length +=
+ urb->iso_frame_desc[i].actual_length;
+ }
+}
+
static int processcompl(struct async *as, void __user * __user *arg)
{
struct urb *urb = as->urb;
@@ -1840,6 +1852,7 @@ static int processcompl(struct async *as
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
goto err_out;
@@ -2008,6 +2021,7 @@ static int processcompl_compat(struct as
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
return -EFAULT;
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 10/28] USB: Add delay-init quirk for Corsair K70 LUX keyboards
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 09/28] USB: usbfs: compute urb->actual_length for isochronous Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 11/28] usb: gadget: f_fs: Fix use-after-free in ffs_free_inst Greg Kroah-Hartman
` (18 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bernhard Rosenkraenzer
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bernhard Rosenkraenzer <bernhard.rosenkranzer@linaro.org>
commit a0fea6027f19c62727315aba1a7fae75a9caa842 upstream.
Without this patch, K70 LUX keyboards don't work, saying
usb 3-3: unable to read config index 0 descriptor/all
usb 3-3: can't read configurations, error -110
usb usb3-port3: unable to enumerate USB device
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -221,6 +221,9 @@ static const struct usb_device_id usb_qu
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ /* Corsair K70 LUX */
+ { USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* MIDI keyboard WORLDE MINI */
{ USB_DEVICE(0x1c75, 0x0204), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 11/28] usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 10/28] USB: Add delay-init quirk for Corsair K70 LUX keyboards Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:43 ` [PATCH 4.13 12/28] USB: serial: metro-usb: stop I/O after failed open Greg Kroah-Hartman
` (17 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrew Gabbasov, Felipe Balbi
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Gabbasov <andrew_gabbasov@mentor.com>
commit cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream.
KASAN enabled configuration reports an error
BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
Write of size 8 by task ...
This is observed after "ffs-test" is run and interrupted. If after that
functionfs is unmounted and g_ffs module is unloaded, that use-after-free
occurs during g_ffs module removal.
Although the report indicates ffs_free_inst() function, the actual
use-after-free condition occurs in _ffs_free_dev() function, which
is probably inlined into ffs_free_inst().
This happens due to keeping the ffs_data reference in device structure
during functionfs unmounting, while ffs_data itself is freed as no longer
needed. The fix is to clear that reference in ffs_closed() function,
which is a counterpart of ffs_ready(), where the reference is stored.
Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3669,6 +3669,7 @@ static void ffs_closed(struct ffs_data *
goto done;
ffs_obj->desc_ready = false;
+ ffs_obj->ffs_data = NULL;
if (test_and_clear_bit(FFS_FL_CALL_CLOSED_CALLBACK, &ffs->flags) &&
ffs_obj->ffs_closed_callback)
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 12/28] USB: serial: metro-usb: stop I/O after failed open
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 11/28] usb: gadget: f_fs: Fix use-after-free in ffs_free_inst Greg Kroah-Hartman
@ 2017-11-19 14:43 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 13/28] USB: serial: Change DbC debug device binding ID Greg Kroah-Hartman
` (16 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 2339536d229df25c71c0900fc619289229bfecf6 upstream.
Make sure to kill the interrupt-in URB after a failed open request.
Apart from saving power (and avoiding stale input after a later
successful open), this also prevents a NULL-deref in the completion
handler if the port is manually unbound.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: 704577861d5e ("USB: serial: metro-usb: get data from device in Uni-Directional mode.")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/metro-usb.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/usb/serial/metro-usb.c
+++ b/drivers/usb/serial/metro-usb.c
@@ -189,7 +189,7 @@ static int metrousb_open(struct tty_stru
dev_err(&port->dev,
"%s - failed submitting interrupt in urb, error code=%d\n",
__func__, result);
- goto exit;
+ return result;
}
/* Send activate cmd to device */
@@ -198,9 +198,14 @@ static int metrousb_open(struct tty_stru
dev_err(&port->dev,
"%s - failed to configure device, error code=%d\n",
__func__, result);
- goto exit;
+ goto err_kill_urb;
}
-exit:
+
+ return 0;
+
+err_kill_urb:
+ usb_kill_urb(port->interrupt_in_urb);
+
return result;
}
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 13/28] USB: serial: Change DbC debug device binding ID
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-11-19 14:43 ` [PATCH 4.13 12/28] USB: serial: metro-usb: stop I/O after failed open Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 14/28] USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update Greg Kroah-Hartman
` (15 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold, Lu Baolu
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Baolu <baolu.lu@linux.intel.com>
commit 12f28144cf2cf69e1520e238eee7c384719ca44b upstream.
The product ID for "Linux USB GDB Target device" has been
changed. Change the driver binding table accordingly.
This patch should be back-ported to kernels as old as v4.12,
that contain the commit 57fb47279a04 ("usb/serial: Add DBC
debug device support to usb_debug").
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/usb_debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -34,13 +34,13 @@ static const struct usb_device_id id_tab
};
static const struct usb_device_id dbc_id_table[] = {
- { USB_DEVICE(0x1d6b, 0x0004) },
+ { USB_DEVICE(0x1d6b, 0x0011) },
{ },
};
static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(0x0525, 0x127a) },
- { USB_DEVICE(0x1d6b, 0x0004) },
+ { USB_DEVICE(0x1d6b, 0x0011) },
{ },
};
MODULE_DEVICE_TABLE(usb, id_table_combined);
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 14/28] USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 13/28] USB: serial: Change DbC debug device binding ID Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 15/28] USB: serial: garmin_gps: fix I/O after failed probe and remove Greg Kroah-Hartman
` (14 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Douglas Fischer, Johan Hovold
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Fischer <douglas.fischer@outlook.com>
commit 771394a54148f18926ca86414e51c69eda27d0cd upstream.
Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update
mode.
Signed-off-by: Douglas Fischer <douglas.fischer@outlook.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/qcserial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -148,6 +148,7 @@ static const struct usb_device_id id_tab
{DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */
{DEVICE_SWI(0x1199, 0x68c0)}, /* Sierra Wireless MC7304/MC7354 */
{DEVICE_SWI(0x1199, 0x901c)}, /* Sierra Wireless EM7700 */
+ {DEVICE_SWI(0x1199, 0x901e)}, /* Sierra Wireless EM7355 QDL */
{DEVICE_SWI(0x1199, 0x901f)}, /* Sierra Wireless EM7355 */
{DEVICE_SWI(0x1199, 0x9040)}, /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9041)}, /* Sierra Wireless MC7305/MC7355 */
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 15/28] USB: serial: garmin_gps: fix I/O after failed probe and remove
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 14/28] USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 16/28] USB: serial: garmin_gps: fix memory leak on probe errors Greg Kroah-Hartman
` (13 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 upstream.
Make sure to stop any submitted interrupt and bulk-out URBs before
returning after failed probe and when the port is being unbound to avoid
later NULL-pointer dereferences in the completion callbacks.
Also fix up the related and broken I/O cancellation on failed open and
on close. (Note that port->write_urb was never submitted.)
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/garmin_gps.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/usb/serial/garmin_gps.c
+++ b/drivers/usb/serial/garmin_gps.c
@@ -138,6 +138,7 @@ struct garmin_data {
__u8 privpkt[4*6];
spinlock_t lock;
struct list_head pktlist;
+ struct usb_anchor write_urbs;
};
@@ -905,7 +906,7 @@ static int garmin_init_session(struct us
sizeof(GARMIN_START_SESSION_REQ), 0);
if (status < 0)
- break;
+ goto err_kill_urbs;
}
if (status > 0)
@@ -913,6 +914,12 @@ static int garmin_init_session(struct us
}
return status;
+
+err_kill_urbs:
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
+ usb_kill_urb(port->interrupt_in_urb);
+
+ return status;
}
@@ -930,7 +937,6 @@ static int garmin_open(struct tty_struct
spin_unlock_irqrestore(&garmin_data_p->lock, flags);
/* shutdown any bulk reads that might be going on */
- usb_kill_urb(port->write_urb);
usb_kill_urb(port->read_urb);
if (garmin_data_p->state == STATE_RESET)
@@ -953,7 +959,7 @@ static void garmin_close(struct usb_seri
/* shutdown our urbs */
usb_kill_urb(port->read_urb);
- usb_kill_urb(port->write_urb);
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
/* keep reset state so we know that we must start a new session */
if (garmin_data_p->state != STATE_RESET)
@@ -1037,12 +1043,14 @@ static int garmin_write_bulk(struct usb_
}
/* send it down the pipe */
+ usb_anchor_urb(urb, &garmin_data_p->write_urbs);
status = usb_submit_urb(urb, GFP_ATOMIC);
if (status) {
dev_err(&port->dev,
"%s - usb_submit_urb(write bulk) failed with status = %d\n",
__func__, status);
count = status;
+ usb_unanchor_urb(urb);
kfree(buffer);
}
@@ -1401,6 +1409,7 @@ static int garmin_port_probe(struct usb_
garmin_data_p->state = 0;
garmin_data_p->flags = 0;
garmin_data_p->count = 0;
+ init_usb_anchor(&garmin_data_p->write_urbs);
usb_set_serial_port_data(port, garmin_data_p);
status = garmin_init_session(port);
@@ -1413,6 +1422,7 @@ static int garmin_port_remove(struct usb
{
struct garmin_data *garmin_data_p = usb_get_serial_port_data(port);
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
usb_kill_urb(port->interrupt_in_urb);
del_timer_sync(&garmin_data_p->timer);
kfree(garmin_data_p);
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 16/28] USB: serial: garmin_gps: fix memory leak on probe errors
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 15/28] USB: serial: garmin_gps: fix I/O after failed probe and remove Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 17/28] selftests/x86/protection_keys: Fix syscall NR redefinition warnings Greg Kroah-Hartman
` (12 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 74d471b598444b7f2d964930f7234779c80960a0 upstream.
Make sure to free the port private data before returning after a failed
probe attempt.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/garmin_gps.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/usb/serial/garmin_gps.c
+++ b/drivers/usb/serial/garmin_gps.c
@@ -1413,6 +1413,12 @@ static int garmin_port_probe(struct usb_
usb_set_serial_port_data(port, garmin_data_p);
status = garmin_init_session(port);
+ if (status)
+ goto err_free;
+
+ return 0;
+err_free:
+ kfree(garmin_data_p);
return status;
}
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 17/28] selftests/x86/protection_keys: Fix syscall NR redefinition warnings
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 16/28] USB: serial: garmin_gps: fix memory leak on probe errors Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 19/28] platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface Greg Kroah-Hartman
` (11 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Lutomirski, Borislav Petkov,
Dave Hansen, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
Ingo Molnar
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <luto@kernel.org>
commit 693cb5580fdb026922363aa103add64b3ecd572e upstream.
On new enough glibc, the pkey syscalls numbers are available. Check
first before defining them to avoid warnings like:
protection_keys.c:198:0: warning: "SYS_pkey_alloc" redefined
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1fbef53a9e6befb7165ff855fc1a7d4788a191d6.1509794321.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/x86/protection_keys.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
--- a/tools/testing/selftests/x86/protection_keys.c
+++ b/tools/testing/selftests/x86/protection_keys.c
@@ -188,17 +188,29 @@ void lots_o_noops_around_write(int *writ
#define u64 uint64_t
#ifdef __i386__
-#define SYS_mprotect_key 380
-#define SYS_pkey_alloc 381
-#define SYS_pkey_free 382
+
+#ifndef SYS_mprotect_key
+# define SYS_mprotect_key 380
+#endif
+#ifndef SYS_pkey_alloc
+# define SYS_pkey_alloc 381
+# define SYS_pkey_free 382
+#endif
#define REG_IP_IDX REG_EIP
#define si_pkey_offset 0x14
+
#else
-#define SYS_mprotect_key 329
-#define SYS_pkey_alloc 330
-#define SYS_pkey_free 331
+
+#ifndef SYS_mprotect_key
+# define SYS_mprotect_key 329
+#endif
+#ifndef SYS_pkey_alloc
+# define SYS_pkey_alloc 330
+# define SYS_pkey_free 331
+#endif
#define REG_IP_IDX REG_RIP
#define si_pkey_offset 0x20
+
#endif
void dump_mem(void *dumpme, int len_bytes)
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 19/28] platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 17/28] selftests/x86/protection_keys: Fix syscall NR redefinition warnings Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 20/28] platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table Greg Kroah-Hartman
` (10 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Andy Shevchenko
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 upstream.
It seems that the WMI GUID used by the PEAQ 2-in-1 WMI hotkeys is not
as unique as a GUID should be and is used on some other devices too.
This is causing spurious key-press reports on these other devices.
This commits adds a DMI check to the PEAQ 2-in-1 WMI hotkeys driver to
ensure that it is actually running on a PEAQ 2-in-1, fixing the
spurious key-presses on these other devices.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1497861
BugLink: https://bugzilla.suse.com/attachment.cgi?id=743182
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/peaq-wmi.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/drivers/platform/x86/peaq-wmi.c
+++ b/drivers/platform/x86/peaq-wmi.c
@@ -8,6 +8,7 @@
*/
#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <linux/input-polldev.h>
#include <linux/kernel.h>
#include <linux/module.h>
@@ -64,8 +65,22 @@ static void peaq_wmi_poll(struct input_p
}
}
+/* Some other devices (Shuttle XS35) use the same WMI GUID for other purposes */
+static const struct dmi_system_id peaq_dmi_table[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "PEAQ"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"),
+ },
+ },
+};
+
static int __init peaq_wmi_init(void)
{
+ /* WMI GUID is not unique, also check for a DMI match */
+ if (!dmi_check_system(peaq_dmi_table))
+ return -ENODEV;
+
if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID))
return -ENODEV;
@@ -86,6 +101,9 @@ static int __init peaq_wmi_init(void)
static void __exit peaq_wmi_exit(void)
{
+ if (!dmi_check_system(peaq_dmi_table))
+ return;
+
if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID))
return;
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 20/28] platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 19/28] platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 22/28] HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection Greg Kroah-Hartman
` (9 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Fengguang Wu, Hans de Goede,
Andy Shevchenko
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit d6fa71f1c003fb2bc824276bb424a4171f9a717f upstream.
Add missing terminating entry to peaq_dmi_table.
Fixes: 3b95206110a2 ("platform/x86: peaq-wmi: Add DMI check before ...")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/peaq-wmi.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/platform/x86/peaq-wmi.c
+++ b/drivers/platform/x86/peaq-wmi.c
@@ -73,6 +73,7 @@ static const struct dmi_system_id peaq_d
DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"),
},
},
+ {}
};
static int __init peaq_wmi_init(void)
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 22/28] HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 20/28] platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 23/28] staging: wilc1000: Fix bssid buffer offset in Txq Greg Kroah-Hartman
` (8 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ping Cheng, Benjamin Tissoires,
Jason Gerecke, Jiri Kosina
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Gerecke <killertofu@gmail.com>
commit 885e89f601a52cc6fb025b009df58ba83d142734 upstream.
The WACOM_PEN_FIELD macro is used to determine if a given HID field should be
associated with pen input. This field includes several known collection types
that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application
collection type is notably missing. This can result in fields within this
kind of collection being completely ignored by the `wacom_usage_mapping`
function, preventing the later '*_event' functions from being notified about
changes to their value.
Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages")
Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch")
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/wacom_wac.h | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -166,6 +166,7 @@
((f)->physical == HID_DG_PEN) || \
((f)->application == HID_DG_PEN) || \
((f)->application == HID_DG_DIGITIZER) || \
+ ((f)->application == WACOM_HID_WD_PEN) || \
((f)->application == WACOM_HID_WD_DIGITIZER) || \
((f)->application == WACOM_HID_G9_PEN) || \
((f)->application == WACOM_HID_G11_PEN))
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 23/28] staging: wilc1000: Fix bssid buffer offset in Txq
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 22/28] HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 24/28] staging: sm750fb: Fix parameter mistake in poke32 Greg Kroah-Hartman
` (7 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Aditya Shankar
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aditya Shankar <aditya.shankar@microchip.com>
commit 1bbf6a6d4091affb27ec0a19d7aa7887ce72f610 upstream.
Commit 46949b48568b ("staging: wilc1000: New cfg packet
format in handle_set_wfi_drv_handler") updated the frame
format sent from host to the firmware. The code to update
the bssid offset in the new frame was part of a second
patch in the series which did not make it in and thus
causes connection problems after associating to an AP.
This fix adds the proper offset of the bssid value in the
Tx queue buffer to fix the connection issues.
Fixes: 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler")
Signed-off-by: Aditya Shankar <Aditya.Shankar@microchip.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/wilc1000/wilc_wlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_devi
char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid;
buffer_offset = ETH_ETHERNET_HDR_OFFSET;
- memcpy(&txb[offset + 4], bssid, 6);
+ memcpy(&txb[offset + 8], bssid, 6);
} else {
buffer_offset = HOST_HDR_OFFSET;
}
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 24/28] staging: sm750fb: Fix parameter mistake in poke32
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 23/28] staging: wilc1000: Fix bssid buffer offset in Txq Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 25/28] staging: ccree: fix 64 bit scatter/gather DMA ops Greg Kroah-Hartman
` (6 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Huacai Chen, Liangliang Huang
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <chenhc@lemote.com>
commit 16808dcf605e6302319a8c3266789b76d4c0983b upstream.
In commit c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32
by inline functions"), POKE32 has been replaced by the inline function
poke32. But it exchange the "addr" and "data" parameters by mistake, so
fix it.
Fixes: c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"),
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Liangliang Huang <huangll@lemote.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/sm750fb/ddk750_chip.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -17,7 +17,7 @@ static inline u32 peek32(u32 addr)
return readl(addr + mmio750);
}
-static inline void poke32(u32 data, u32 addr)
+static inline void poke32(u32 addr, u32 data)
{
writel(data, addr + mmio750);
}
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 25/28] staging: ccree: fix 64 bit scatter/gather DMA ops
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 24/28] staging: sm750fb: Fix parameter mistake in poke32 Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 26/28] staging: greybus: spilib: fix use-after-free after deregistration Greg Kroah-Hartman
` (5 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Stuart Yoder, Gilad Ben-Yossef
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gilad Ben-Yossef <gilad@benyossef.com>
commit e0b3f39092a1cff5548cbaf40096ec25e7721de6 upstream.
Fix a wrong offset used in splitting a 64 DMA address to MSB/LSB
parts needed for scatter/gather HW descriptors causing operations
relying on them to fail on 64 bit platforms.
Fixes: c6f7f2f4591f ("staging: ccree: refactor LLI access macros")
Reported-by: Stuart Yoder <stuart.yoder@arm.com>
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/ccree/cc_lli_defs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/ccree/cc_lli_defs.h
+++ b/drivers/staging/ccree/cc_lli_defs.h
@@ -59,7 +59,7 @@ static inline void cc_lli_set_addr(u32 *
lli_p[LLI_WORD0_OFFSET] = (addr & U32_MAX);
#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
lli_p[LLI_WORD1_OFFSET] &= ~LLI_HADDR_MASK;
- lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 16));
+ lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 32));
#endif /* CONFIG_ARCH_DMA_ADDR_T_64BIT */
}
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 26/28] staging: greybus: spilib: fix use-after-free after deregistration
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 25/28] staging: ccree: fix 64 bit scatter/gather DMA ops Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 27/28] staging: vboxvideo: Fix reporting invalid suggested-offset-properties Greg Kroah-Hartman
` (4 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johan Hovold, Rui Miguel Silva,
Viresh Kumar
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 770b03c2ca4aa44d226cf248f86aa23e546147d0 upstream.
Remove erroneous spi_master_put() after controller deregistration which
would access the already freed spi controller.
Note that spi_unregister_master() drops our only controller reference.
Fixes: ba3e67001b42 ("greybus: SPI: convert to a gpbridge driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/greybus/spilib.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/staging/greybus/spilib.c
+++ b/drivers/staging/greybus/spilib.c
@@ -544,12 +544,15 @@ int gb_spilib_master_init(struct gb_conn
return 0;
-exit_spi_unregister:
- spi_unregister_master(master);
exit_spi_put:
spi_master_put(master);
return ret;
+
+exit_spi_unregister:
+ spi_unregister_master(master);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(gb_spilib_master_init);
@@ -558,7 +561,6 @@ void gb_spilib_master_exit(struct gb_con
struct spi_master *master = gb_connection_get_data(connection);
spi_unregister_master(master);
- spi_master_put(master);
}
EXPORT_SYMBOL_GPL(gb_spilib_master_exit);
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 27/28] staging: vboxvideo: Fix reporting invalid suggested-offset-properties
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 26/28] staging: greybus: spilib: fix use-after-free after deregistration Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 14:44 ` [PATCH 4.13 28/28] staging: rtl8188eu: Revert 4 commits breaking ARP Greg Kroah-Hartman
` (3 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gianfranco Costamagna, Michael Thayer,
Hans de Goede
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 upstream.
The x and y hints receives from the host are unsigned 32 bit integers and
they get set to -1 (0xffffffff) when invalid. Before this commit the
vboxvideo driver was storing them in an u16 causing the -1 to be truncated
to 65535 which, once reported to userspace, was breaking gnome 3.26+
in Wayland mode.
This commit stores the host values in 32 bit variables, removing the
truncation and checks for -1, replacing it with 0 as -1 is not a valid
suggested-offset-property value. Likewise the properties are now
initialized to 0 instead of -1, since -1 is not a valid value.
This fixes gnome 3.26+ in Wayland mode not working with the vboxvideo
driver.
Reported-by: Gianfranco Costamagna <locutusofborg@debian.org>
Cc: Michael Thayer <michael.thayer@oracle.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/vboxvideo/vbox_drv.h | 8 ++++----
drivers/staging/vboxvideo/vbox_irq.c | 4 ++--
drivers/staging/vboxvideo/vbox_mode.c | 26 ++++++++++++++++++--------
3 files changed, 24 insertions(+), 14 deletions(-)
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -137,8 +137,8 @@ struct vbox_connector {
char name[32];
struct vbox_crtc *vbox_crtc;
struct {
- u16 width;
- u16 height;
+ u32 width;
+ u32 height;
bool disconnected;
} mode_hint;
};
@@ -150,8 +150,8 @@ struct vbox_crtc {
unsigned int crtc_id;
u32 fb_offset;
bool cursor_enabled;
- u16 x_hint;
- u16 y_hint;
+ u32 x_hint;
+ u32 y_hint;
};
struct vbox_encoder {
--- a/drivers/staging/vboxvideo/vbox_irq.c
+++ b/drivers/staging/vboxvideo/vbox_irq.c
@@ -150,8 +150,8 @@ static void vbox_update_mode_hints(struc
disconnected = !(hints->enabled);
crtc_id = vbox_conn->vbox_crtc->crtc_id;
- vbox_conn->mode_hint.width = hints->cx & 0x8fff;
- vbox_conn->mode_hint.height = hints->cy & 0x8fff;
+ vbox_conn->mode_hint.width = hints->cx;
+ vbox_conn->mode_hint.height = hints->cy;
vbox_conn->vbox_crtc->x_hint = hints->dx;
vbox_conn->vbox_crtc->y_hint = hints->dy;
vbox_conn->mode_hint.disconnected = disconnected;
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -560,12 +560,22 @@ static int vbox_get_modes(struct drm_con
++num_modes;
}
vbox_set_edid(connector, preferred_width, preferred_height);
- drm_object_property_set_value(
- &connector->base, vbox->dev->mode_config.suggested_x_property,
- vbox_connector->vbox_crtc->x_hint);
- drm_object_property_set_value(
- &connector->base, vbox->dev->mode_config.suggested_y_property,
- vbox_connector->vbox_crtc->y_hint);
+
+ if (vbox_connector->vbox_crtc->x_hint != -1)
+ drm_object_property_set_value(&connector->base,
+ vbox->dev->mode_config.suggested_x_property,
+ vbox_connector->vbox_crtc->x_hint);
+ else
+ drm_object_property_set_value(&connector->base,
+ vbox->dev->mode_config.suggested_x_property, 0);
+
+ if (vbox_connector->vbox_crtc->y_hint != -1)
+ drm_object_property_set_value(&connector->base,
+ vbox->dev->mode_config.suggested_y_property,
+ vbox_connector->vbox_crtc->y_hint);
+ else
+ drm_object_property_set_value(&connector->base,
+ vbox->dev->mode_config.suggested_y_property, 0);
return num_modes;
}
@@ -650,9 +660,9 @@ static int vbox_connector_init(struct dr
drm_mode_create_suggested_offset_properties(dev);
drm_object_attach_property(&connector->base,
- dev->mode_config.suggested_x_property, -1);
+ dev->mode_config.suggested_x_property, 0);
drm_object_attach_property(&connector->base,
- dev->mode_config.suggested_y_property, -1);
+ dev->mode_config.suggested_y_property, 0);
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
^ permalink raw reply [flat|nested] 45+ messages in thread* [PATCH 4.13 28/28] staging: rtl8188eu: Revert 4 commits breaking ARP
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 27/28] staging: vboxvideo: Fix reporting invalid suggested-offset-properties Greg Kroah-Hartman
@ 2017-11-19 14:44 ` Greg Kroah-Hartman
2017-11-19 20:13 ` [PATCH 4.13 00/28] 4.13.15-stable review Guenter Roeck
` (2 subsequent siblings)
28 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 14:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ivan Safonov, Hans de Goede
4.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 66d32fdcbf03851724a8b551d490ae1ddfe6eef2 upstream.
Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into
decrypt() and also place it after rtl88eu_mon_recv_hook()") breaks ARP.
After this commit ssh-ing to a laptop with r8188eu wifi no longer works
if the machine connecting has never communicated with the laptop before.
This is 100% reproducable using "arp -d <ipv4> && ssh <ipv4>" to ssh to
a laptop with r8188eu wifi.
This commit reverts 4 commits in total:
1. Commit 79650ffde38e ("staging:r8188eu: trim IV/ICV fields in
validate_recv_data_frame()")
This commit depends on 2 of the other commits being reverted.
2. Commit 02b19b4c4920 ("staging:r8188eu: inline unprotect_frame() in
mon_recv_decrypted_recv()")
The inline code is wrong the un-inlined version contains:
if (skb->len < hdr_len + iv_len + icv_len)
return;
...
Where as the inline-ed code introduced by this commit does:
if (skb->len < hdr_len + iv_len + icv_len) {
...
Note the same check, but now to actually continue doing ... instead
of to not do it, so this commit is no good.
3. Commit d86e16da6a5d ("staging:r8188eu: use different mon_recv_decrypted()
inside rtl88eu_mon_recv_hook() and rtl88eu_mon_xmit_hook().")
This commit introduced a 1:1 copy of a function so that one of the
2 copies can be modified in the 2 commits we're already reverting.
4. Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into
decrypt() and also place it after rtl88eu_mon_recv_hook()")
This is the commit actually breaking ARP.
Note this commit is a straight-forward squash of the revert of these
4 commits, without any changes.
Cc: Ivan Safonov <insafonov@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_recv.c | 83 ++++++++++++++++++------------
drivers/staging/rtl8188eu/os_dep/mon.c | 34 +-----------
2 files changed, 55 insertions(+), 62 deletions(-)
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -259,10 +259,12 @@ static int recvframe_chkmic(struct adapt
}
/* icv_len included the mic code */
- datalen = precvframe->pkt->len-prxattrib->hdrlen - 8;
+ datalen = precvframe->pkt->len-prxattrib->hdrlen -
+ prxattrib->iv_len-prxattrib->icv_len-8;
pframe = precvframe->pkt->data;
- payload = pframe+prxattrib->hdrlen;
+ payload = pframe+prxattrib->hdrlen+prxattrib->iv_len;
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n prxattrib->iv_len=%d prxattrib->icv_len=%d\n", prxattrib->iv_len, prxattrib->icv_len));
rtw_seccalctkipmic(mickey, pframe, payload, datalen, &miccode[0],
(unsigned char)prxattrib->priority); /* care the length of the data */
@@ -407,15 +409,9 @@ static struct recv_frame *decryptor(stru
default:
break;
}
- if (res != _FAIL) {
- memmove(precv_frame->pkt->data + precv_frame->attrib.iv_len, precv_frame->pkt->data, precv_frame->attrib.hdrlen);
- skb_pull(precv_frame->pkt, precv_frame->attrib.iv_len);
- skb_trim(precv_frame->pkt, precv_frame->pkt->len - precv_frame->attrib.icv_len);
- }
} else if (prxattrib->bdecrypted == 1 && prxattrib->encrypt > 0 &&
- (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) {
- psecuritypriv->hw_decrypted = true;
- }
+ (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_))
+ psecuritypriv->hw_decrypted = true;
if (res == _FAIL) {
rtw_free_recvframe(return_packet, &padapter->recvpriv.free_recv_queue);
@@ -456,7 +452,7 @@ static struct recv_frame *portctrl(struc
if (auth_alg == 2) {
/* get ether_type */
- ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE;
+ ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE + pfhdr->attrib.iv_len;
memcpy(&be_tmp, ptr, 2);
ether_type = ntohs(be_tmp);
@@ -1138,8 +1134,6 @@ static int validate_recv_data_frame(stru
}
if (pattrib->privacy) {
- struct sk_buff *skb = precv_frame->pkt;
-
RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("validate_recv_data_frame:pattrib->privacy=%x\n", pattrib->privacy));
RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n ^^^^^^^^^^^IS_MCAST(pattrib->ra(0x%02x))=%d^^^^^^^^^^^^^^^6\n", pattrib->ra[0], IS_MCAST(pattrib->ra)));
@@ -1148,13 +1142,6 @@ static int validate_recv_data_frame(stru
RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n pattrib->encrypt=%d\n", pattrib->encrypt));
SET_ICE_IV_LEN(pattrib->iv_len, pattrib->icv_len, pattrib->encrypt);
-
- if (pattrib->bdecrypted == 1 && pattrib->encrypt > 0) {
- memmove(skb->data + pattrib->iv_len,
- skb->data, pattrib->hdrlen);
- skb_pull(skb, pattrib->iv_len);
- skb_trim(skb, skb->len - pattrib->icv_len);
- }
} else {
pattrib->encrypt = 0;
pattrib->iv_len = 0;
@@ -1274,7 +1261,6 @@ static int validate_recv_frame(struct ad
* Hence forward the frame to the monitor anyway to preserve the order
* in which frames were received.
*/
-
rtl88eu_mon_recv_hook(adapter->pmondev, precv_frame);
exit:
@@ -1296,8 +1282,11 @@ static int wlanhdr_to_ethhdr(struct recv
u8 *ptr = precvframe->pkt->data;
struct rx_pkt_attrib *pattrib = &precvframe->attrib;
- psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen);
- psnap_type = ptr+pattrib->hdrlen + SNAP_SIZE;
+ if (pattrib->encrypt)
+ skb_trim(precvframe->pkt, precvframe->pkt->len - pattrib->icv_len);
+
+ psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen + pattrib->iv_len);
+ psnap_type = ptr+pattrib->hdrlen + pattrib->iv_len+SNAP_SIZE;
/* convert hdr + possible LLC headers into Ethernet header */
if ((!memcmp(psnap, rtw_rfc1042_header, SNAP_SIZE) &&
(!memcmp(psnap_type, SNAP_ETH_TYPE_IPX, 2) == false) &&
@@ -1310,9 +1299,12 @@ static int wlanhdr_to_ethhdr(struct recv
bsnaphdr = false;
}
- rmv_len = pattrib->hdrlen + (bsnaphdr ? SNAP_SIZE : 0);
+ rmv_len = pattrib->hdrlen + pattrib->iv_len + (bsnaphdr ? SNAP_SIZE : 0);
len = precvframe->pkt->len - rmv_len;
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_info_,
+ ("\n===pattrib->hdrlen: %x, pattrib->iv_len:%x===\n\n", pattrib->hdrlen, pattrib->iv_len));
+
memcpy(&be_tmp, ptr+rmv_len, 2);
eth_type = ntohs(be_tmp); /* pattrib->ether_type */
pattrib->eth_type = eth_type;
@@ -1337,6 +1329,7 @@ static struct recv_frame *recvframe_defr
struct __queue *defrag_q)
{
struct list_head *plist, *phead;
+ u8 wlanhdr_offset;
u8 curfragnum;
struct recv_frame *pfhdr, *pnfhdr;
struct recv_frame *prframe, *pnextrframe;
@@ -1385,7 +1378,12 @@ static struct recv_frame *recvframe_defr
/* copy the 2nd~n fragment frame's payload to the first fragment */
/* get the 2nd~last fragment frame's payload */
- skb_pull(pnextrframe->pkt, pnfhdr->attrib.hdrlen);
+ wlanhdr_offset = pnfhdr->attrib.hdrlen + pnfhdr->attrib.iv_len;
+
+ skb_pull(pnextrframe->pkt, wlanhdr_offset);
+
+ /* append to first fragment frame's tail (if privacy frame, pull the ICV) */
+ skb_trim(prframe->pkt, prframe->pkt->len - pfhdr->attrib.icv_len);
/* memcpy */
memcpy(skb_tail_pointer(pfhdr->pkt), pnfhdr->pkt->data,
@@ -1393,7 +1391,7 @@ static struct recv_frame *recvframe_defr
skb_put(prframe->pkt, pnfhdr->pkt->len);
- pfhdr->attrib.icv_len = 0;
+ pfhdr->attrib.icv_len = pnfhdr->attrib.icv_len;
plist = plist->next;
}
@@ -1519,6 +1517,11 @@ static int amsdu_to_msdu(struct adapter
nr_subframes = 0;
pattrib = &prframe->attrib;
+ skb_pull(prframe->pkt, prframe->attrib.hdrlen);
+
+ if (prframe->attrib.iv_len > 0)
+ skb_pull(prframe->pkt, prframe->attrib.iv_len);
+
a_len = prframe->pkt->len;
pdata = prframe->pkt->data;
@@ -1887,6 +1890,24 @@ static int process_recv_indicatepkts(str
return retval;
}
+static int recv_func_prehandle(struct adapter *padapter,
+ struct recv_frame *rframe)
+{
+ int ret = _SUCCESS;
+ struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
+
+ /* check the frame crtl field and decache */
+ ret = validate_recv_frame(padapter, rframe);
+ if (ret != _SUCCESS) {
+ RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n"));
+ rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */
+ goto exit;
+ }
+
+exit:
+ return ret;
+}
+
static int recv_func_posthandle(struct adapter *padapter,
struct recv_frame *prframe)
{
@@ -1939,7 +1960,6 @@ static int recv_func(struct adapter *pad
struct rx_pkt_attrib *prxattrib = &rframe->attrib;
struct security_priv *psecuritypriv = &padapter->securitypriv;
struct mlme_priv *mlmepriv = &padapter->mlmepriv;
- struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
/* check if need to handle uc_swdec_pending_queue*/
if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && psecuritypriv->busetkipkey) {
@@ -1951,12 +1971,9 @@ static int recv_func(struct adapter *pad
}
}
- /* check the frame crtl field and decache */
- ret = validate_recv_frame(padapter, rframe);
- if (ret != _SUCCESS) {
- RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n"));
- rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */
- } else {
+ ret = recv_func_prehandle(padapter, rframe);
+
+ if (ret == _SUCCESS) {
/* check if need to enqueue into uc_swdec_pending_queue*/
if (check_fwstate(mlmepriv, WIFI_STATION_STATE) &&
!IS_MCAST(prxattrib->ra) && prxattrib->encrypt > 0 &&
--- a/drivers/staging/rtl8188eu/os_dep/mon.c
+++ b/drivers/staging/rtl8188eu/os_dep/mon.c
@@ -66,34 +66,6 @@ static void mon_recv_decrypted(struct ne
netif_rx(skb);
}
-static void mon_recv_decrypted_recv(struct net_device *dev, const u8 *data,
- int data_len)
-{
- struct sk_buff *skb;
- struct ieee80211_hdr *hdr;
- int hdr_len;
-
- skb = netdev_alloc_skb(dev, data_len);
- if (!skb)
- return;
- memcpy(skb_put(skb, data_len), data, data_len);
-
- /*
- * Frame data is not encrypted. Strip off protection so
- * userspace doesn't think that it is.
- */
-
- hdr = (struct ieee80211_hdr *)skb->data;
- hdr_len = ieee80211_hdrlen(hdr->frame_control);
-
- if (ieee80211_has_protected(hdr->frame_control))
- hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_PROTECTED);
-
- skb->ip_summed = CHECKSUM_UNNECESSARY;
- skb->protocol = eth_type_trans(skb, dev);
- netif_rx(skb);
-}
-
static void mon_recv_encrypted(struct net_device *dev, const u8 *data,
int data_len)
{
@@ -110,6 +82,7 @@ static void mon_recv_encrypted(struct ne
void rtl88eu_mon_recv_hook(struct net_device *dev, struct recv_frame *frame)
{
struct rx_pkt_attrib *attr;
+ int iv_len, icv_len;
int data_len;
u8 *data;
@@ -122,8 +95,11 @@ void rtl88eu_mon_recv_hook(struct net_de
data = frame->pkt->data;
data_len = frame->pkt->len;
+ /* Broadcast and multicast frames don't have attr->{iv,icv}_len set */
+ SET_ICE_IV_LEN(iv_len, icv_len, attr->encrypt);
+
if (attr->bdecrypted)
- mon_recv_decrypted_recv(dev, data, data_len);
+ mon_recv_decrypted(dev, data, data_len, iv_len, icv_len);
else
mon_recv_encrypted(dev, data, data_len);
}
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2017-11-19 14:44 ` [PATCH 4.13 28/28] staging: rtl8188eu: Revert 4 commits breaking ARP Greg Kroah-Hartman
@ 2017-11-19 20:13 ` Guenter Roeck
2017-11-20 14:13 ` Guenter Roeck
2017-11-20 21:18 ` Shuah Khan
28 siblings, 0 replies; 45+ messages in thread
From: Guenter Roeck @ 2017-11-19 20:13 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.13.15 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
> Anything received after that time might be too late.
>
Build reference: v4.13.14-29-g6493632
Building arm:allmodconfig ... failed
--------------
Error log:
/opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function 'mailbox_send_message':
/opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member 'dev' in something not a structure or union
struct device *dev = &(iproc_priv.pdev->dev);
^
make[4]: *** [drivers/crypto/bcm/cipher.o] Error 1
make[3]: *** [drivers/crypto/bcm] Error 2
Building arm64:allmodconfig ... failed
--------------
Error log:
arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
arch/arm64/Makefile:36: LSE atomics not supported by binutils
/opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function ‘mailbox_send_message’:
/opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member ‘dev’ in something not a structure or union
struct device *dev = &(iproc_priv.pdev->dev);
^
make[4]: *** [drivers/crypto/bcm/cipher.o] Error 1
make[3]: *** [drivers/crypto/bcm] Error 2
Early report; builds are incomplete. I do see that another pull is scheduled,
so it may well be that this has already been fixed. If so, apologies for the noise.
Guenter
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2017-11-19 20:13 ` [PATCH 4.13 00/28] 4.13.15-stable review Guenter Roeck
@ 2017-11-20 14:13 ` Guenter Roeck
2017-11-21 7:23 ` Greg Kroah-Hartman
2017-11-20 21:18 ` Shuah Khan
28 siblings, 1 reply; 45+ messages in thread
From: Guenter Roeck @ 2017-11-20 14:13 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.13.15 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 143 fail: 2
Failed builds:
arm:allmodconfig
arm64:allmodconfig
Qemu test results:
total: 123 pass: 107 fail: 16
Failed tests:
arm:beagle:multi_v7_defconfig:omap3-beagle
arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
arm:overo:multi_v7_defconfig:omap3-overo-tobi
arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
arm:midway:multi_v7_defconfig:ecx-2000
arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
arm64:virt:smp:defconfig
arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
arm64:virt:nosmp:defconfig
arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
Error ias always the same.
Building arm:allmodconfig ... failed
--------------
Error log:
/opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function 'mailbox_send_message':
/opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member 'dev' in something not a structure or union
struct device *dev = &(iproc_priv.pdev->dev);
^
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 45+ messages in thread* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-20 14:13 ` Guenter Roeck
@ 2017-11-21 7:23 ` Greg Kroah-Hartman
2017-11-21 7:51 ` Greg Kroah-Hartman
0 siblings, 1 reply; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-21 7:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote:
> On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.13.15 release.
> > There are 28 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 145 pass: 143 fail: 2
> Failed builds:
> arm:allmodconfig
> arm64:allmodconfig
> Qemu test results:
> total: 123 pass: 107 fail: 16
> Failed tests:
> arm:beagle:multi_v7_defconfig:omap3-beagle
> arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> arm:overo:multi_v7_defconfig:omap3-overo-tobi
> arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
> arm:midway:multi_v7_defconfig:ecx-2000
> arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
> arm64:virt:smp:defconfig
> arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
> arm64:virt:nosmp:defconfig
> arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
>
> Error ias always the same.
>
> Building arm:allmodconfig ... failed
> --------------
> Error log:
> /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function 'mailbox_send_message':
> /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member 'dev' in something not a structure or union
> struct device *dev = &(iproc_priv.pdev->dev);
Ugh, I missed this yesterday, I'll go try to figure out how I broke
this, and how my test builds missed this...
greg k-h
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-21 7:23 ` Greg Kroah-Hartman
@ 2017-11-21 7:51 ` Greg Kroah-Hartman
2017-11-21 10:06 ` Guenter Roeck
0 siblings, 1 reply; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-21 7:51 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
On Tue, Nov 21, 2017 at 08:23:20AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote:
> > On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.13.15 release.
> > > There are 28 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
> > > Anything received after that time might be too late.
> > >
> >
> > Build results:
> > total: 145 pass: 143 fail: 2
> > Failed builds:
> > arm:allmodconfig
> > arm64:allmodconfig
> > Qemu test results:
> > total: 123 pass: 107 fail: 16
> > Failed tests:
> > arm:beagle:multi_v7_defconfig:omap3-beagle
> > arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> > arm:overo:multi_v7_defconfig:omap3-overo-tobi
> > arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
> > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> > arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
> > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
> > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
> > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
> > arm:midway:multi_v7_defconfig:ecx-2000
> > arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
> > arm64:virt:smp:defconfig
> > arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
> > arm64:virt:nosmp:defconfig
> > arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
> >
> > Error ias always the same.
> >
> > Building arm:allmodconfig ... failed
> > --------------
> > Error log:
> > /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function 'mailbox_send_message':
> > /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member 'dev' in something not a structure or union
> > struct device *dev = &(iproc_priv.pdev->dev);
>
> Ugh, I missed this yesterday, I'll go try to figure out how I broke
> this, and how my test builds missed this...
Ok, I think I've found it, and now dropped the offending patch.
greg k-h
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-21 7:51 ` Greg Kroah-Hartman
@ 2017-11-21 10:06 ` Guenter Roeck
2017-11-21 14:15 ` Greg Kroah-Hartman
0 siblings, 1 reply; 45+ messages in thread
From: Guenter Roeck @ 2017-11-21 10:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
On 11/20/2017 11:51 PM, Greg Kroah-Hartman wrote:
> On Tue, Nov 21, 2017 at 08:23:20AM +0100, Greg Kroah-Hartman wrote:
>> On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote:
>>> On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 4.13.15 release.
>>>> There are 28 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Build results:
>>> total: 145 pass: 143 fail: 2
>>> Failed builds:
>>> arm:allmodconfig
>>> arm64:allmodconfig
>>> Qemu test results:
>>> total: 123 pass: 107 fail: 16
>>> Failed tests:
>>> arm:beagle:multi_v7_defconfig:omap3-beagle
>>> arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
>>> arm:overo:multi_v7_defconfig:omap3-overo-tobi
>>> arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
>>> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>>> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>>> arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
>>> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
>>> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
>>> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
>>> arm:midway:multi_v7_defconfig:ecx-2000
>>> arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
>>> arm64:virt:smp:defconfig
>>> arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
>>> arm64:virt:nosmp:defconfig
>>> arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
>>>
>>> Error ias always the same.
>>>
>>> Building arm:allmodconfig ... failed
>>> --------------
>>> Error log:
>>> /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function 'mailbox_send_message':
>>> /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member 'dev' in something not a structure or union
>>> struct device *dev = &(iproc_priv.pdev->dev);
>>
>> Ugh, I missed this yesterday, I'll go try to figure out how I broke
>> this, and how my test builds missed this...
>
> Ok, I think I've found it, and now dropped the offending patch.
>
With v4.13.14-28-g92df2ce:
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 123 pass: 123 fail: 0
Guenter
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-21 10:06 ` Guenter Roeck
@ 2017-11-21 14:15 ` Greg Kroah-Hartman
0 siblings, 0 replies; 45+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-21 14:15 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
On Tue, Nov 21, 2017 at 02:06:25AM -0800, Guenter Roeck wrote:
> On 11/20/2017 11:51 PM, Greg Kroah-Hartman wrote:
> > On Tue, Nov 21, 2017 at 08:23:20AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Nov 20, 2017 at 06:13:42AM -0800, Guenter Roeck wrote:
> > > > On 11/19/2017 06:43 AM, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 4.13.15 release.
> > > > > There are 28 patches in this series, all will be posted as a response
> > > > > to this one. If anyone has any issues with these being applied, please
> > > > > let me know.
> > > > >
> > > > > Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
> > > > > Anything received after that time might be too late.
> > > > >
> > > >
> > > > Build results:
> > > > total: 145 pass: 143 fail: 2
> > > > Failed builds:
> > > > arm:allmodconfig
> > > > arm64:allmodconfig
> > > > Qemu test results:
> > > > total: 123 pass: 107 fail: 16
> > > > Failed tests:
> > > > arm:beagle:multi_v7_defconfig:omap3-beagle
> > > > arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> > > > arm:overo:multi_v7_defconfig:omap3-overo-tobi
> > > > arm:sabrelite:multi_v7_defconfig:imx6dl-sabrelite
> > > > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> > > > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> > > > arm:vexpress-a15-a7:multi_v7_defconfig:vexpress-v2p-ca15_a7
> > > > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
> > > > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
> > > > arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
> > > > arm:midway:multi_v7_defconfig:ecx-2000
> > > > arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
> > > > arm64:virt:smp:defconfig
> > > > arm64:xlnx-ep108:smp:defconfig:zynqmp-ep108
> > > > arm64:virt:nosmp:defconfig
> > > > arm64:xlnx-ep108:nosmp:defconfig:zynqmp-ep108
> > > >
> > > > Error ias always the same.
> > > >
> > > > Building arm:allmodconfig ... failed
> > > > --------------
> > > > Error log:
> > > > /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c: In function 'mailbox_send_message':
> > > > /opt/buildbot/slave/stable-queue-4.13/build/drivers/crypto/bcm/cipher.c:266:40: error: request for member 'dev' in something not a structure or union
> > > > struct device *dev = &(iproc_priv.pdev->dev);
> > >
> > > Ugh, I missed this yesterday, I'll go try to figure out how I broke
> > > this, and how my test builds missed this...
> >
> > Ok, I think I've found it, and now dropped the offending patch.
> >
>
> With v4.13.14-28-g92df2ce:
>
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 123 pass: 123 fail: 0
Great, thanks for confirming that this was resolved.
greg k-h
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 4.13 00/28] 4.13.15-stable review
2017-11-19 14:43 [PATCH 4.13 00/28] 4.13.15-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2017-11-20 14:13 ` Guenter Roeck
@ 2017-11-20 21:18 ` Shuah Khan
28 siblings, 0 replies; 45+ messages in thread
From: Shuah Khan @ 2017-11-20 21:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, Shuah Khan
On 11/19/2017 07:43 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.13.15 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Tue Nov 21 14:42:57 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 45+ messages in thread