user/sven/linux.git, branch v5.10.84

Linux 5.10.84

2021-12-08T08:03:30Z

Link: https://lore.kernel.org/r/20211206145559.607158688@linuxfoundation.org Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Fox Chen Link: https://lore.kernel.org/r/20211207081114.760201765@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) = Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

ipmi: msghandler: Make symbol 'remove_work_wq' static

2021-12-08T08:03:29Z

commit 5a3ba99b62d8486de0316334e72ac620d4b94fdd upstream. The sparse tool complains as follows: drivers/char/ipmi/ipmi_msghandler.c:194:25: warning: symbol 'remove_work_wq' was not declared. Should it be static? This symbol is not used outside of ipmi_msghandler.c, so marks it static. Fixes: 1d49eb91e86e ("ipmi: Move remove_work to dedicated workqueue") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Message-Id: <20211123083618.2366808-1-weiyongjun1@huawei.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

net/tls: Fix authentication failure in CCM mode

2021-12-08T08:03:29Z

commit 5961060692f8b17cd2080620a3d27b95d2ae05ca upstream. When the TLS cipher suite uses CCM mode, including AES CCM and SM4 CCM, the first byte of the B0 block is flags, and the real IV starts from the second byte. The XOR operation of the IV and rec_seq should be skip this byte, that is, add the iv_offset. Fixes: f295b3ae9f59 ("net/tls: Add support of AES128-CCM based ciphers") Signed-off-by: Tianjia Zhang Cc: Vakul Garg Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

parisc: Mark cr16 CPU clocksource unstable on all SMP machines

2021-12-08T08:03:29Z

commit afdb4a5b1d340e4afffc65daa21cc71890d7d589 upstream. In commit c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources") I assumed that CPUs on the same physical core are syncronous. While booting up the kernel on two different C8000 machines, one with a dual-core PA8800 and one with a dual-core PA8900 CPU, this turned out to be wrong. The symptom was that I saw a jump in the internal clocks printed to the syslog and strange overall behaviour. On machines which have 4 cores (2 dual-cores) the problem isn't visible, because the current logic already marked the cr16 clocksource unstable in this case. This patch now marks the cr16 interval timers unstable if we have more than one CPU in the system, and it fixes this issue. Fixes: c8c3735997a3 ("parisc: Enhance detection of synchronous cr16 clocksources") Signed-off-by: Helge Deller Cc: # v5.15+ Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: retry init flow if failed

2021-12-08T08:03:29Z

commit 5283dd677e52af9db6fe6ad11b2f12220d519d0c upstream. In some very rare cases the init flow may fail. In many cases, this is recoverable, so we can retry. Implement a loop to retry two more times after the first attempt failed. This can happen in two different situations, namely during probe and during mac80211 start. For the first case, a simple loop is enough. For the second case, we need to add a flag to prevent mac80211 from trying to restart it as well, leaving full control with the driver. Cc: Signed-off-by: Mordechay Goodstein Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid Signed-off-by: Greg Kroah-Hartman

serial: 8250: Fix RTS modem control while in rs485 mode

2021-12-08T08:03:29Z

commit f85e04503f369b3f2be28c83fc48b74e19936ebc upstream. Commit f45709df7731 ("serial: 8250: Don't touch RTS modem control while in rs485 mode") sought to prevent user space from interfering with rs485 communication by ignoring a TIOCMSET ioctl() which changes RTS polarity. It did so in serial8250_do_set_mctrl(), which turns out to be too deep in the call stack: When a uart_port is opened, RTS polarity is set by the rs485-aware function uart_port_dtr_rts(). It calls down to serial8250_do_set_mctrl() and that particular RTS polarity change should *not* be ignored. The user-visible result is that on 8250_omap ports which use rs485 with inverse polarity (RTS bit in MCR register is 1 to receive, 0 to send), a newly opened port initially sets up RTS for sending instead of receiving. That's because omap_8250_startup() sets the cached value up->mcr to 0 and omap_8250_restore_regs() subsequently writes it to the MCR register. Due to the commit, serial8250_do_set_mctrl() preserves that incorrect register value: do_sys_openat2 do_filp_open path_openat vfs_open do_dentry_open chrdev_open tty_open uart_open tty_port_open uart_port_activate uart_startup uart_port_startup serial8250_startup omap_8250_startup # up->mcr = 0 uart_change_speed serial8250_set_termios omap_8250_set_termios omap_8250_restore_regs serial8250_out_MCR # up->mcr written tty_port_block_til_ready uart_dtr_rts uart_port_dtr_rts serial8250_set_mctrl omap8250_set_mctrl serial8250_do_set_mctrl # mcr[1] = 1 ignored Fix by intercepting RTS changes from user space in uart_tiocmset() instead. Link: https://lore.kernel.org/linux-serial/20211027111644.1996921-1-baocheng.su@siemens.com/ Fixes: f45709df7731 ("serial: 8250: Don't touch RTS modem control while in rs485 mode") Cc: Chao Zeng Cc: stable@vger.kernel.org # v5.7+ Reported-by: Su Bao Cheng Reported-by: Jan Kiszka Tested-by: Su Bao Cheng Signed-off-by: Lukas Wunner Link: https://lore.kernel.org/r/21170e622a1aaf842a50b32146008b5374b3dd1d.1637596432.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: rewrite pericom_do_set_divisor()

2021-12-08T08:03:29Z

commit bb1201d4b38ec67bd9a871cf86b0cc10f28b15b5 upstream. Have pericom_do_set_divisor() use the uartclk instead of a hard coded value to work with different speed crystals. Tested with 14.7456 and 24 MHz crystals. Have pericom_do_set_divisor() always calculate the divisor rather than call serial8250_do_set_divisor() for rates below baud_base. Do not write registers or call serial8250_do_set_divisor() if valid divisors could not be found. Fixes: 6bf4e42f1d19 ("serial: 8250: Add support for higher baud rates to Pericom chips") Cc: stable Signed-off-by: Jay Dolan Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20211122120604.3909-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_pci: Fix ACCES entries in pci_serial_quirks array

2021-12-08T08:03:29Z

commit c525c5d2437f93520388920baac6d9340c65d239 upstream. Fix error in table for PCI_DEVICE_ID_ACCESIO_PCIE_ICM_4S that caused it and PCI_DEVICE_ID_ACCESIO_PCIE_ICM232_4 to be missing their fourth port. Fixes: 78d3820b9bd3 ("serial: 8250_pci: Have ACCES cards that use the four port Pericom PI7C9X7954 chip use the pci_pericom_setup()") Cc: stable Signed-off-by: Jay Dolan Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20211122120604.3909-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman

serial: core: fix transmit-buffer reset and memleak

2021-12-08T08:03:29Z

commit 00de977f9e0aa9760d9a79d1e41ff780f74e3424 upstream. Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). Link: https://lore.kernel.org/r/319321886d97c456203d5c6a576a5480d07c3478.1635781688.git.baruch@tkos.co.il Fixes: 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") Cc: stable@vger.kernel.org # 4.9 Cc: Rob Herring Reported-by: Baruch Siach Tested-by: Baruch Siach Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211108085431.12637-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: tegra: Change lower tolerance baud rate limit for tegra20 and tegra30

2021-12-08T08:03:29Z

commit b40de7469ef135161c80af0e8c462298cc5dac00 upstream. The current implementation uses 0 as lower limit for the baud rate tolerance for tegra20 and tegra30 chips which causes isses on UART initialization as soon as baud rate clock is lower than required even when within the standard UART tolerance of +/- 4%. This fix aligns the implementation with the initial commit description of +/- 4% tolerance for tegra chips other than tegra186 and tegra194. Fixes: d781ec21bae6 ("serial: tegra: report clk rate errors") Cc: stable Signed-off-by: Patrik John Link: https://lore.kernel.org/r/sig.19614244f8.20211123132737.88341-1-patrik.john@u-blox.com Signed-off-by: Greg Kroah-Hartman