This is a note to let you know that I've just added the patch titled
Add delay-init quirk for Corsair K70 RGB keyboards
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7a1646d922577b5b48c0d222e03831141664bb59 Mon Sep 17 00:00:00 2001
From: Jack Stocker <jackstocker.93(a)gmail.com>
Date: Thu, 15 Feb 2018 18:24:10 +0000
Subject: Add delay-init quirk for Corsair K70 RGB keyboards
From: Jack Stocker <jackstocker.93(a)gmail.com>
commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.
Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
Signed-off-by: Jack Stocker <jackstocker.93(a)gmail.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)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
@@ -225,6 +225,9 @@ static const struct usb_device_id usb_qu
{ USB_DEVICE(0x1a0a, 0x0200), .driver_info =
USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
+ /* Corsair K70 RGB */
+ { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
Patches currently in stable-queue which might be from jackstocker.93(a)gmail.com are
queue-4.4/add-delay-init-quirk-for-corsair-k70-rgb-keyboards.patch
This is a note to let you know that I've just added the patch titled
x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 85c615eb52222bc5fab6c7190d146bc59fac289e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 20 Feb 2018 21:58:21 +0100
Subject: x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
From: Arnd Bergmann <arnd(a)arndb.de>
commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
data from CPU 0 to all other CPUs, which when building a non-SMP
kernel turns into a memcpy() with identical source and destination
pointers:
arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
memcpy(per_cpu(cpu_msrs, cpu).multiplex,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
per_cpu(cpu_msrs, 0).multiplex,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(struct op_msr) * model->num_virt_counters);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
I have analyzed a number of such warnings now: some are valid and the
GCC warning is welcome. Others turned out to be false-positives, and
GCC was changed to not warn about those any more. This is a corner case
that is a false-positive but the GCC developers feel it's better to keep
warning about it.
In this case, it seems best to work around it by telling GCC
a little more clearly that this code path is never hit with
an IS_ENABLED() configuration check.
Cc:stable as we also want old kernels to build cleanly with GCC-8.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Jessica Yu <jeyu(a)kernel.org>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Martin Sebor <msebor(a)gcc.gnu.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Robert Richter <rric(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: oprofile-list(a)lists.sf.net
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/oprofile/nmi_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -471,7 +471,7 @@ static int nmi_setup(void)
goto fail;
for_each_possible_cpu(cpu) {
- if (!cpu)
+ if (!IS_ENABLED(CONFIG_SMP) || !cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-3.18/cfg80211-fix-cfg80211_beacon_dup.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Process all descriptors during bind
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-f_fs-process-all-descriptors-during-bind.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6cf439e0d37463e42784271179c8a308fd7493c6 Mon Sep 17 00:00:00 2001
From: Jack Pham <jackp(a)codeaurora.org>
Date: Wed, 24 Jan 2018 00:11:53 -0800
Subject: usb: gadget: f_fs: Process all descriptors during bind
From: Jack Pham <jackp(a)codeaurora.org>
commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2727,10 +2727,8 @@ static int _ffs_func_bind(struct usb_con
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
Patches currently in stable-queue which might be from jackp(a)codeaurora.org are
queue-3.18/usb-gadget-f_fs-process-all-descriptors-during-bind.patch
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: Set maxpacket size for ep0 IN
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6180026341e852a250e1f97ebdcf71684a3c81b9 Mon Sep 17 00:00:00 2001
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Date: Fri, 12 Jan 2018 18:18:05 -0800
Subject: usb: dwc3: gadget: Set maxpacket size for ep0 IN
From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
There are 2 control endpoint structures for DWC3. However, the driver
only updates the OUT direction control endpoint structure during
ConnectDone event. DWC3 driver needs to update the endpoint max packet
size for control IN endpoint as well. If the max packet size is not
properly set, then the driver will incorrectly calculate the data
transfer size and fail to send ZLP for HS/FS 3-stage control read
transfer.
The fix is simply to update the max packet size for the ep0 IN direction
during ConnectDone event.
Cc: stable(a)vger.kernel.org
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/dwc3/gadget.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2345,6 +2345,8 @@ static void dwc3_gadget_conndone_interru
break;
}
+ dwc->eps[1]->endpoint.maxpacket = dwc->gadget.ep0->maxpacket;
+
/* Enable USB2 LPM Capability */
if ((dwc->revision > DWC3_REVISION_194A)
Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are
queue-3.18/usb-dwc3-gadget-set-maxpacket-size-for-ep0-in.patch
This is a note to let you know that I've just added the patch titled
scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c39813652700f3df552b6557530f1e5f782dbe2f Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Date: Tue, 23 Jan 2018 20:11:32 -0600
Subject: scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
From: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
The fcp_rsp_info structure as defined in the FC spec has an initial 3
bytes reserved field. The ibmvfc driver mistakenly defined this field as
4 bytes resulting in the rsp_code field being defined in what should be
the start of the second reserved field and thus always being reported as
zero by the driver.
Ideally, we should wire ibmvfc up with libfc for the sake of code
deduplication, and ease of maintaining standardized structures in a
single place. However, for now simply fixup the definition in ibmvfc for
backporting to distros on older kernels. Wiring up with libfc will be
done in a followup patch.
Cc: <stable(a)vger.kernel.org>
Reported-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Tyrel Datwyler <tyreld(a)linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/ibmvscsi/ibmvfc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/ibmvscsi/ibmvfc.h
+++ b/drivers/scsi/ibmvscsi/ibmvfc.h
@@ -366,7 +366,7 @@ enum ibmvfc_fcp_rsp_info_codes {
};
struct ibmvfc_fcp_rsp_info {
- __be16 reserved;
+ u8 reserved[3];
u8 rsp_code;
u8 reserved2[4];
}__attribute__((packed, aligned (2)));
Patches currently in stable-queue which might be from tyreld(a)linux.vnet.ibm.com are
queue-3.18/scsi-ibmvfc-fix-misdefined-reserved-field-in-ibmvfc_fcp_rsp_info.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 21ec30c0ef5234fb1039cc7c7737d885bf875a9e Mon Sep 17 00:00:00 2001
From: Shanker Donthineni <shankerd(a)codeaurora.org>
Date: Wed, 31 Jan 2018 18:03:42 -0600
Subject: irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
From: Shanker Donthineni <shankerd(a)codeaurora.org>
commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Cc: stable(a)vger.kernel.org
Acked-by: Will Deacon <will.deacon(a)arm.com>,
Signed-off-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -503,7 +503,7 @@ static void gic_raise_softirq(const stru
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- smp_wmb();
+ wmb();
for_each_cpu_mask(cpu, *mask) {
u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
Patches currently in stable-queue which might be from shankerd(a)codeaurora.org are
queue-3.18/irqchip-gic-v3-use-wmb-instead-of-smb_wmb-in-gic_raise_softirq.patch
This is a note to let you know that I've just added the patch titled
iio: buffer: check if a buffer has been set up when poll is called
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4cd140bda6494543f1c1b0ccceceaa44b676eef6 Mon Sep 17 00:00:00 2001
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Date: Thu, 15 Feb 2018 15:02:53 +0100
Subject: iio: buffer: check if a buffer has been set up when poll is called
From: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt(a)axis.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -92,7 +92,7 @@ unsigned int iio_buffer_poll(struct file
struct iio_dev *indio_dev = filp->private_data;
struct iio_buffer *rb = indio_dev->buffer;
- if (!indio_dev->info)
+ if (!indio_dev->info || rb == NULL)
return 0;
poll_wait(filp, &rb->pollq, wait);
Patches currently in stable-queue which might be from stefan.windfeldt(a)axis.com are
queue-3.18/iio-buffer-check-if-a-buffer-has-been-set-up-when-poll-is-called.patch
This is a note to let you know that I've just added the patch titled
iio: adis_lib: Initialize trigger before requesting interrupt
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f027e0b3a774e10302207e91d304bbf99e3a8b36 Mon Sep 17 00:00:00 2001
From: Lars-Peter Clausen <lars(a)metafoo.de>
Date: Wed, 14 Feb 2018 15:43:00 +0100
Subject: iio: adis_lib: Initialize trigger before requesting interrupt
From: Lars-Peter Clausen <lars(a)metafoo.de>
commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.
iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.
It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).
But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device. This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c0004000
[00000008] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
Hardware name: Xilinx Zynq Platform
task: ef04f640 task.stack: ef050000
PC is at iio_trigger_notify_done+0x30/0x68
LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
pc : [<c042d868>] lr : [<c042d924>] psr: 60000193
sp : ef051bb8 ip : 00000000 fp : ef106400
r10: c081d80a r9 : ef3bfa00 r8 : 00000087
r7 : ef051bec r6 : 00000000 r5 : ef3bfa00 r4 : ee92ab00
r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : ee97e400
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 18c5387d Table: 0000404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xef050210)
[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
To fix this make sure that the trigger is fully initialized before
requesting the interrupt.
Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz <Robin.Getz(a)analog.com>
Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/imu/adis_trigger.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/iio/imu/adis_trigger.c
+++ b/drivers/iio/imu/adis_trigger.c
@@ -47,6 +47,10 @@ int adis_probe_trigger(struct adis *adis
if (adis->trig == NULL)
return -ENOMEM;
+ adis->trig->dev.parent = &adis->spi->dev;
+ adis->trig->ops = &adis_trigger_ops;
+ iio_trigger_set_drvdata(adis->trig, adis);
+
ret = request_irq(adis->spi->irq,
&iio_trigger_generic_data_rdy_poll,
IRQF_TRIGGER_RISING,
@@ -55,9 +59,6 @@ int adis_probe_trigger(struct adis *adis
if (ret)
goto error_free_trig;
- adis->trig->dev.parent = &adis->spi->dev;
- adis->trig->ops = &adis_trigger_ops;
- iio_trigger_set_drvdata(adis->trig, adis);
ret = iio_trigger_register(adis->trig);
indio_dev->trig = iio_trigger_get(adis->trig);
Patches currently in stable-queue which might be from lars(a)metafoo.de are
queue-3.18/iio-adis_lib-initialize-trigger-before-requesting-interrupt.patch
This is a note to let you know that I've just added the patch titled
cfg80211: fix cfg80211_beacon_dup
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cfg80211-fix-cfg80211_beacon_dup.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From bee92d06157fc39d5d7836a061c7d41289a55797 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Fri, 2 Feb 2018 16:31:23 +0100
Subject: cfg80211: fix cfg80211_beacon_dup
From: Arnd Bergmann <arnd(a)arndb.de>
commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
gcc-8 warns about some obviously incorrect code:
net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
>From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.
Cc: stable(a)vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/mac80211/cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2769,7 +2769,7 @@ cfg80211_beacon_dup(struct cfg80211_beac
}
if (beacon->probe_resp_len) {
new_beacon->probe_resp_len = beacon->probe_resp_len;
- beacon->probe_resp = pos;
+ new_beacon->probe_resp = pos;
memcpy(pos, beacon->probe_resp, beacon->probe_resp_len);
pos += beacon->probe_resp_len;
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/x86-oprofile-fix-bogus-gcc-8-warning-in-nmi_setup.patch
queue-3.18/cfg80211-fix-cfg80211_beacon_dup.patch