--- /dev/null
+From f4c23a140d80ef5e6d3d1f8f57007649014b60fa Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Tue, 21 Jul 2020 14:38:52 +0000
+Subject: serial: 8250: fix null-ptr-deref in serial8250_start_tx()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+commit f4c23a140d80ef5e6d3d1f8f57007649014b60fa upstream.
+
+I got null-ptr-deref in serial8250_start_tx():
+
+[ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
+[ 78.123778] Mem abort info:
+[ 78.126560] ESR = 0x86000007
+[ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits
+[ 78.134891] SET = 0, FnV = 0
+[ 78.137933] EA = 0, S1PTW = 0
+[ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600
+[ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000
+[ 78.160029] Internal error: Oops: 86000007 [#1] SMP
+[ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd
+[ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48
+[ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020
+[ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
+[ 78.228435] pc : 0x0
+[ 78.230618] lr : serial8250_start_tx+0x160/0x260
+[ 78.235215] sp : ffff800062eefb80
+[ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff
+[ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000
+[ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000
+[ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002
+[ 78.259679] x21: 0000000000000001 x20: 0000000000000000
+[ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000
+[ 78.270259] x17: 0000000000000000 x16: 0000000000000000
+[ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6
+[ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539
+[ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0
+[ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88
+[ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000
+[ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8
+[ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002
+[ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8
+[ 78.317873] Call trace:
+[ 78.320312] 0x0
+[ 78.322147] __uart_start.isra.9+0x64/0x78
+[ 78.326229] uart_start+0xb8/0x1c8
+[ 78.329620] uart_flush_chars+0x24/0x30
+[ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30
+[ 78.338128] n_tty_receive_buf+0x44/0x2c8
+[ 78.342122] tty_ioctl+0x348/0x11f8
+[ 78.345599] ksys_ioctl+0xd8/0xf8
+[ 78.348903] __arm64_sys_ioctl+0x2c/0xc8
+[ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0
+[ 78.357583] do_el0_svc+0x44/0xd0
+[ 78.360887] el0_sync_handler+0x14c/0x1d0
+[ 78.364880] el0_sync+0x140/0x180
+[ 78.368185] Code: bad PC value
+
+SERIAL_PORT_DFNS is not defined on each arch, if it's not defined,
+serial8250_set_defaults() won't be called in serial8250_isa_init_ports(),
+so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref.
+Fix this problem by calling serial8250_set_defaults() after init uart port.
+
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/8250/8250_core.c
++++ b/drivers/tty/serial/8250/8250_core.c
+@@ -530,6 +530,7 @@ static void __init serial8250_isa_init_p
+ */
+ up->mcr_mask = ~ALPHA_KLUDGE_MCR;
+ up->mcr_force = ALPHA_KLUDGE_MCR;
++ serial8250_set_defaults(up);
+ }
+
+ /* chain base port ops to support Remote Supervisor Adapter */
+@@ -553,7 +554,6 @@ static void __init serial8250_isa_init_p
+ port->membase = old_serial_port[i].iomem_base;
+ port->iotype = old_serial_port[i].io_type;
+ port->regshift = old_serial_port[i].iomem_reg_shift;
+- serial8250_set_defaults(up);
+
+ port->irqflags |= irqflag;
+ if (serial8250_isa_config != NULL)
--- /dev/null
+From 551e553f0d4ab623e2a6f424ab5834f9c7b5229c Mon Sep 17 00:00:00 2001
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Date: Tue, 14 Jul 2020 15:41:12 +0300
+Subject: serial: 8250_mtk: Fix high-speed baud rates clamping
+
+From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+
+commit 551e553f0d4ab623e2a6f424ab5834f9c7b5229c upstream.
+
+Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250
+port") fixed limits of a baud rate setting for a generic 8250 port.
+In other words since that commit the baud rate has been permitted to be
+within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely
+normal for a standard 8250 UART port. But there are custom 8250 ports,
+which provide extended baud rate limits. In particular the Mediatek 8250
+port can work with baud rates up to "uartclk" speed.
+
+Normally that and any other peculiarity is supposed to be handled in a
+custom set_termios() callback implemented in the vendor-specific
+8250-port glue-driver. Currently that is how it's done for the most of
+the vendor-specific 8250 ports, but for some reason for Mediatek a
+solution has been spread out to both the glue-driver and to the generic
+8250-port code. Due to that a bug has been introduced, which permitted the
+extended baud rate limit for all even for standard 8250-ports. The bug
+has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud
+limit in generic 8250 port") by narrowing the baud rates limit back down to
+the normal bounds. Unfortunately by doing so we also broke the
+Mediatek-specific extended bauds feature.
+
+A fix of the problem described above is twofold. First since we can't get
+back the extended baud rate limits feature to the generic set_termios()
+function and that method supports only a standard baud rates range, the
+requested baud rate must be locally stored before calling it and then
+restored back to the new termios structure after the generic set_termios()
+finished its magic business. By doing so we still use the
+serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers,
+while the extended baud rate setting procedure will be performed later in
+the custom Mediatek-specific set_termios() callback. Second since a true
+baud rate is now fully calculated in the custom set_termios() method we
+need to locally update the port timeout by calling the
+uart_update_timeout() function. After the fixes described above are
+implemented in the 8250_mtk.c driver, the Mediatek 8250-port should
+get back to normally working with extended baud rates.
+
+Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com
+
+Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port")
+Reported-by: Daniel Winkler <danielwinkler@google.com>
+Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
+Cc: stable <stable@vger.kernel.org>
+Tested-by: Claire Chang <tientzu@chromium.org>
+Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/8250/8250_mtk.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/tty/serial/8250/8250_mtk.c
++++ b/drivers/tty/serial/8250/8250_mtk.c
+@@ -47,8 +47,21 @@ mtk8250_set_termios(struct uart_port *po
+ struct uart_8250_port *up =
+ container_of(port, struct uart_8250_port, port);
+
++ /*
++ * Store the requested baud rate before calling the generic 8250
++ * set_termios method. Standard 8250 port expects bauds to be
++ * no higher than (uartclk / 16) so the baud will be clamped if it
++ * gets out of that bound. Mediatek 8250 port supports speed
++ * higher than that, therefore we'll get original baud rate back
++ * after calling the generic set_termios method and recalculate
++ * the speed later in this method.
++ */
++ baud = tty_termios_baud_rate(termios);
++
+ serial8250_do_set_termios(port, termios, old);
+
++ tty_termios_encode_baud_rate(termios, baud, baud);
++
+ /*
+ * Mediatek UARTs use an extra highspeed register (UART_MTK_HIGHS)
+ *
+@@ -91,6 +104,11 @@ mtk8250_set_termios(struct uart_port *po
+ */
+ spin_lock_irqsave(&port->lock, flags);
+
++ /*
++ * Update the per-port timeout.
++ */
++ uart_update_timeout(port, termios->c_cflag, baud);
++
+ /* set DLAB we have cval saved in up->lcr from the call to the core */
+ serial_port_out(port, UART_LCR, up->lcr | UART_LCR_DLAB);
+ serial_dl_write(up, quot);
x86-math-emu-fix-up-cmp-insn-for-clang-ias.patch
revert-cifs-fix-the-target-file-was-deleted-when-rename-failed.patch
staging-wlan-ng-properly-check-endpoint-types.patch
+staging-comedi-addi_apci_1032-check-insn_config_digital_trig-shift.patch
+staging-comedi-ni_6527-fix-insn_config_digital_trig-support.patch
+staging-comedi-addi_apci_1500-check-insn_config_digital_trig-shift.patch
+staging-comedi-addi_apci_1564-check-insn_config_digital_trig-shift.patch
+serial-8250-fix-null-ptr-deref-in-serial8250_start_tx.patch
+serial-8250_mtk-fix-high-speed-baud-rates-clamping.patch
--- /dev/null
+From 0bd0db42a030b75c20028c7ba6e327b9cb554116 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:55 +0100
+Subject: staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 0bd0db42a030b75c20028c7ba6e327b9cb554116 upstream.
+
+The `INSN_CONFIG` comedi instruction with sub-instruction code
+`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
+used as a right shift amount for other bitmask values without being
+checked. Shift amounts greater than or equal to 32 will result in
+undefined behavior. Add code to deal with this.
+
+Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG")
+Cc: <stable@vger.kernel.org> #3.8+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/addi_apci_1032.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/addi_apci_1032.c
++++ b/drivers/staging/comedi/drivers/addi_apci_1032.c
+@@ -115,14 +115,22 @@ static int apci1032_cos_insn_config(stru
+ unsigned int *data)
+ {
+ struct apci1032_private *devpriv = dev->private;
+- unsigned int shift, oldmask;
++ unsigned int shift, oldmask, himask, lomask;
+
+ switch (data[0]) {
+ case INSN_CONFIG_DIGITAL_TRIG:
+ if (data[1] != 0)
+ return -EINVAL;
+ shift = data[3];
+- oldmask = (1U << shift) - 1;
++ if (shift < 32) {
++ oldmask = (1U << shift) - 1;
++ himask = data[4] << shift;
++ lomask = data[5] << shift;
++ } else {
++ oldmask = 0xffffffffu;
++ himask = 0;
++ lomask = 0;
++ }
+ switch (data[2]) {
+ case COMEDI_DIGITAL_TRIG_DISABLE:
+ devpriv->ctrl = 0;
+@@ -145,8 +153,8 @@ static int apci1032_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ case COMEDI_DIGITAL_TRIG_ENABLE_LEVELS:
+ if (devpriv->ctrl != (APCI1032_CTRL_INT_ENA |
+@@ -163,8 +171,8 @@ static int apci1032_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:57 +0100
+Subject: staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d upstream.
+
+The `INSN_CONFIG` comedi instruction with sub-instruction code
+`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
+used as a right shift amount for other bitmask values without being
+checked. Shift amounts greater than or equal to 32 will result in
+undefined behavior. Add code to deal with this, adjusting the checks
+for invalid channels so that enabled channel bits that would have been
+lost by shifting are also checked for validity. Only channels 0 to 15
+are valid.
+
+Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions")
+Cc: <stable@vger.kernel.org> #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it
+Cc: <stable@vger.kernel.org> #4.0+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/addi_apci_1500.c | 24 +++++++++++++++++++-----
+ 1 file changed, 19 insertions(+), 5 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/addi_apci_1500.c
++++ b/drivers/staging/comedi/drivers/addi_apci_1500.c
+@@ -461,13 +461,14 @@ static int apci1500_di_cfg_trig(struct c
+ struct apci1500_private *devpriv = dev->private;
+ unsigned int trig = data[1];
+ unsigned int shift = data[3];
+- unsigned int hi_mask = data[4] << shift;
+- unsigned int lo_mask = data[5] << shift;
+- unsigned int chan_mask = hi_mask | lo_mask;
+- unsigned int old_mask = (1 << shift) - 1;
++ unsigned int hi_mask;
++ unsigned int lo_mask;
++ unsigned int chan_mask;
++ unsigned int old_mask;
+ unsigned int pm;
+ unsigned int pt;
+ unsigned int pp;
++ unsigned int invalid_chan;
+
+ if (trig > 1) {
+ dev_dbg(dev->class_dev,
+@@ -475,7 +476,20 @@ static int apci1500_di_cfg_trig(struct c
+ return -EINVAL;
+ }
+
+- if (chan_mask > 0xffff) {
++ if (shift <= 16) {
++ hi_mask = data[4] << shift;
++ lo_mask = data[5] << shift;
++ old_mask = (1U << shift) - 1;
++ invalid_chan = (data[4] | data[5]) >> (16 - shift);
++ } else {
++ hi_mask = 0;
++ lo_mask = 0;
++ old_mask = 0xffff;
++ invalid_chan = data[4] | data[5];
++ }
++ chan_mask = hi_mask | lo_mask;
++
++ if (invalid_chan) {
+ dev_dbg(dev->class_dev, "invalid digital trigger channel\n");
+ return -EINVAL;
+ }
--- /dev/null
+From 926234f1b8434c4409aa4c53637aa3362ca07cea Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:56 +0100
+Subject: staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 926234f1b8434c4409aa4c53637aa3362ca07cea upstream.
+
+The `INSN_CONFIG` comedi instruction with sub-instruction code
+`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
+used as a right shift amount for other bitmask values without being
+checked. Shift amounts greater than or equal to 32 will result in
+undefined behavior. Add code to deal with this.
+
+Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions")
+Cc: <stable@vger.kernel.org> #3.17+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/addi_apci_1564.c | 20 ++++++++++++++------
+ 1 file changed, 14 insertions(+), 6 deletions(-)
+
+--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
++++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
+@@ -288,14 +288,22 @@ static int apci1564_cos_insn_config(stru
+ unsigned int *data)
+ {
+ struct apci1564_private *devpriv = dev->private;
+- unsigned int shift, oldmask;
++ unsigned int shift, oldmask, himask, lomask;
+
+ switch (data[0]) {
+ case INSN_CONFIG_DIGITAL_TRIG:
+ if (data[1] != 0)
+ return -EINVAL;
+ shift = data[3];
+- oldmask = (1U << shift) - 1;
++ if (shift < 32) {
++ oldmask = (1U << shift) - 1;
++ himask = data[4] << shift;
++ lomask = data[5] << shift;
++ } else {
++ oldmask = 0xffffffffu;
++ himask = 0;
++ lomask = 0;
++ }
+ switch (data[2]) {
+ case COMEDI_DIGITAL_TRIG_DISABLE:
+ devpriv->ctrl = 0;
+@@ -319,8 +327,8 @@ static int apci1564_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ case COMEDI_DIGITAL_TRIG_ENABLE_LEVELS:
+ if (devpriv->ctrl != (APCI1564_DI_IRQ_ENA |
+@@ -337,8 +345,8 @@ static int apci1564_cos_insn_config(stru
+ devpriv->mode2 &= oldmask;
+ }
+ /* configure specified channels */
+- devpriv->mode1 |= data[4] << shift;
+- devpriv->mode2 |= data[5] << shift;
++ devpriv->mode1 |= himask;
++ devpriv->mode2 |= lomask;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From f07804ec77d77f8a9dcf570a24154e17747bc82f Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Fri, 17 Jul 2020 15:52:54 +0100
+Subject: staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit f07804ec77d77f8a9dcf570a24154e17747bc82f upstream.
+
+`ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions
+for the "interrupt" subdevice. When `data[0]` is
+`INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When
+`data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising
+and falling edge detection for the digital trigger, using a base channel
+number (or shift amount) in `data[3]`, a rising edge bitmask in
+`data[4]` and falling edge bitmask in `data[5]`.
+
+If the base channel number (shift amount) is greater than or equal to
+the number of channels (24) of the digital input subdevice, there are no
+changes to the rising and falling edges, so the mask of channels to be
+changed can be set to 0, otherwise the mask of channels to be changed,
+and the rising and falling edge bitmasks are shifted by the base channel
+number before calling `ni6527_set_edge_detection()` to change the
+appropriate registers. Unfortunately, the code is comparing the base
+channel (shift amount) to the interrupt subdevice's number of channels
+(1) instead of the digital input subdevice's number of channels (24).
+Fix it by comparing to 32 because all shift amounts for an `unsigned
+int` must be less than that and everything from bit 24 upwards is
+ignored by `ni6527_set_edge_detection()` anyway.
+
+Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG")
+Cc: <stable@vger.kernel.org> # 3.17+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/comedi/drivers/ni_6527.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/staging/comedi/drivers/ni_6527.c
++++ b/drivers/staging/comedi/drivers/ni_6527.c
+@@ -341,7 +341,7 @@ static int ni6527_intr_insn_config(struc
+ case COMEDI_DIGITAL_TRIG_ENABLE_EDGES:
+ /* check shift amount */
+ shift = data[3];
+- if (shift >= s->n_chan) {
++ if (shift >= 32) {
+ mask = 0;
+ rising = 0;
+ falling = 0;
projects / thirdparty / kernel / stable-queue.git / commitdiff
