kernel/linux.git, branch v5.16.12

Linux 5.16.12

2022-03-02T10:51:22+00:00

Link: https://lore.kernel.org/r/20220228172359.567256961@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Ronald Warsow Tested-by: Zan Aziz Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Bagas Sanjaya Tested-by: Fenil Jain Tested-by: Rudi Heitbaum Tested-by: Ron Economos Tested-by: Justin M. Forbes Tested-by: Guenter Roeck Tested-by: Slade Watkins Signed-off-by: Greg Kroah-Hartman

memblock: use kfree() to release kmalloced memblock regions

2022-03-02T10:51:22+00:00

commit c94afc46cae7ad41b2ad6a99368147879f4b0e56 upstream. memblock.{reserved,memory}.regions may be allocated using kmalloc() in memblock_double_array(). Use kfree() to release these kmalloced regions indicated by memblock_{reserved,memory}_in_slab. Signed-off-by: Miaohe Lin Fixes: 3010f876500f ("mm: discard memblock data later") Signed-off-by: Mike Rapoport Signed-off-by: Greg Kroah-Hartman

gpio: tegra186: Fix chip_data type confusion

2022-03-02T10:51:21+00:00

commit d1e972ace42390de739cde87d96043dcbe502286 upstream. The tegra186 GPIO driver makes the assumption that the pointer returned by irq_data_get_irq_chip_data() is a pointer to a tegra_gpio structure. Unfortunately, it is actually a pointer to the inner gpio_chip structure, as mandated by the gpiolib infrastructure. Nice try. The saving grace is that the gpio_chip is the first member of tegra_gpio, so the bug has gone undetected since... forever. Fix it by performing a container_of() on the pointer. This results in no additional code, and makes it possible to understand how the whole thing works. Fixes: 5b2b135a87fc ("gpio: Add Tegra186 support") Signed-off-by: Marc Zyngier Cc: Thierry Reding Cc: Linus Walleij Cc: Bartosz Golaszewski Link: https://lore.kernel.org/r/20220211093904.1112679-1-maz@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: k210: Fix bias-pull-up

2022-03-02T10:51:21+00:00

commit e9f7b9228a94778edb7a63fde3c0a3c5bb793064 upstream. Using bias-pull-up would actually cause the pin to have its pull-down enabled. Fix this. Signed-off-by: Sean Anderson Reviewed-by: Damien Le Moal Fixes: d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver") Link: https://lore.kernel.org/r/20220209182822.640905-1-seanga2@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: fix loop in k210_pinconf_get_drive()

2022-03-02T10:51:21+00:00

commit ba2ab85951c91a140a8fa51d8347d54e59ec009d upstream. The loop exited too early so the k210_pinconf_drive_strength[0] array element was never used. Fixes: d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver") Signed-off-by: Dan Carpenter Reviewed-by: Damien Le Moal Reviewed-by: Sean Anderson Link: https://lore.kernel.org/r/20220209180804.GA18385@kili Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: fix deadlock in gsmtty_open()

2022-03-02T10:51:21+00:00

commit a2ab75b8e76e455af7867e3835fd9cdf386b508f upstream. In the current implementation the user may open a virtual tty which then could fail to establish the underlying DLCI. The function gsmtty_open() gets stuck in tty_port_block_til_ready() while waiting for a carrier rise. This happens if the remote side fails to acknowledge the link establishment request in time or completely. At some point gsm_dlci_close() is called to abort the link establishment attempt. The function tries to inform the associated virtual tty by performing a hangup. But the blocking loop within tty_port_block_til_ready() is not informed about this event. The patch proposed here fixes this by resetting the initialization state of the virtual tty to ensure the loop exits and triggering it to make tty_port_block_til_ready() return. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220218073123.2121-7-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: fix wrong modem processing in convergence layer type 2

2022-03-02T10:51:21+00:00

commit 687f9ad43c52501f46164758e908a5dd181a87fc upstream. The function gsm_process_modem() exists to handle modem status bits of incoming frames. This includes incoming MSC (modem status command) frames and convergence layer type 2 data frames. The function, however, was only designed to handle MSC frames as it expects the command length. Within gsm_dlci_data() it is wrongly assumed that this is the same as the data frame length. This is only true if the data frame contains only 1 byte of payload. This patch names the length parameter of gsm_process_modem() in a generic manner to reflect its association. It also corrects all calls to the function to handle the variable number of modem status octets correctly in both cases. Fixes: 7263287af93d ("tty: n_gsm: Fixed logic to decode break signal from modem status") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220218073123.2121-6-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: fix wrong tty control line for flow control

2022-03-02T10:51:21+00:00

commit c19d93542a6081577e6da9bf5e887979c72e80c1 upstream. tty flow control is handled via gsmtty_throttle() and gsmtty_unthrottle(). Both functions propagate the outgoing hardware flow control state to the remote side via MSC (modem status command) frames. The local state is taken from the RTS (ready to send) flag of the tty. However, RTS gets mapped to DTR (data terminal ready), which is wrong. This patch corrects this by mapping RTS to RTS. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220218073123.2121-5-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: fix NULL pointer access due to DLCI release

2022-03-02T10:51:20+00:00

commit 96b169f05cdcc844b400695184d77e42071d14f2 upstream. The here fixed commit made the tty hangup asynchronous to avoid a circular locking warning. I could not reproduce this warning. Furthermore, due to the asynchronous hangup the function call now gets queued up while the underlying tty is being freed. Depending on the timing this results in a NULL pointer access in the global work queue scheduler. To be precise in process_one_work(). Therefore, the previous commit made the issue worse which it tried to fix. This patch fixes this by falling back to the old behavior which uses a blocking tty hangup call before freeing up the associated tty. Fixes: 7030082a7415 ("tty: n_gsm: avoid recursive locking with async port hangup") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220218073123.2121-4-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: fix proper link termination after failed open

2022-03-02T10:51:20+00:00

commit e3b7468f082d106459e86e8dc6fb9bdd65553433 upstream. Trying to open a DLCI by sending a SABM frame may fail with a timeout. The link is closed on the initiator side without informing the responder about this event. The responder assumes the link is open after sending a UA frame to answer the SABM frame. The link gets stuck in a half open state. This patch fixes this by initiating the proper link termination procedure after link setup timeout instead of silently closing it down. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220218073123.2121-3-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman