--- /dev/null
+From 0f9fee4cdebfbe695c297e5b603a275e2557c1cc Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Sat, 4 Dec 2021 21:14:40 +0100
+Subject: parisc: Fix "make install" on newer debian releases
+
+From: Helge Deller <deller@gmx.de>
+
+commit 0f9fee4cdebfbe695c297e5b603a275e2557c1cc upstream.
+
+On newer debian releases the debian-provided "installkernel" script is
+installed in /usr/sbin. Fix the kernel install.sh script to look for the
+script in this directory as well.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: <stable@vger.kernel.org> # v3.13+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/install.sh | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/parisc/install.sh
++++ b/arch/parisc/install.sh
+@@ -39,6 +39,7 @@ verify "$3"
+ if [ -n "${INSTALLKERNEL}" ]; then
+ if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
+ if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
++ if [ -x /usr/sbin/${INSTALLKERNEL} ]; then exec /usr/sbin/${INSTALLKERNEL} "$@"; fi
+ fi
+
+ # Default install
--- /dev/null
+From 00de977f9e0aa9760d9a79d1e41ff780f74e3424 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Nov 2021 09:54:31 +0100
+Subject: serial: core: fix transmit-buffer reset and memleak
+
+From: Johan Hovold <johan@kernel.org>
+
+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 <robh@kernel.org>
+Reported-by: Baruch Siach <baruch@tkos.co.il>
+Tested-by: Baruch Siach <baruch@tkos.co.il>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://lore.kernel.org/r/20211108085431.12637-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/serial_core.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -1522,6 +1522,7 @@ static void uart_tty_port_shutdown(struc
+ {
+ struct uart_state *state = container_of(port, struct uart_state, port);
+ struct uart_port *uport = uart_port_check(state);
++ char *buf;
+
+ /*
+ * At this point, we stop accepting input. To do this, we
+@@ -1543,8 +1544,18 @@ static void uart_tty_port_shutdown(struc
+ */
+ tty_port_set_suspended(port, 0);
+
+- uart_change_pm(state, UART_PM_STATE_OFF);
++ /*
++ * Free the transmit buffer.
++ */
++ spin_lock_irq(&uport->lock);
++ buf = state->xmit.buf;
++ state->xmit.buf = NULL;
++ spin_unlock_irq(&uport->lock);
++
++ if (buf)
++ free_page((unsigned long)buf);
+
++ uart_change_pm(state, UART_PM_STATE_OFF);
+ }
+
+ static void uart_wait_until_sent(struct tty_struct *tty, int timeout)
--- /dev/null
+From ac442a077acf9a6bf1db4320ec0c3f303be092b3 Mon Sep 17 00:00:00 2001
+From: Pierre Gondois <Pierre.Gondois@arm.com>
+Date: Tue, 9 Nov 2021 17:22:48 +0000
+Subject: serial: pl011: Add ACPI SBSA UART match id
+
+From: Pierre Gondois <Pierre.Gondois@arm.com>
+
+commit ac442a077acf9a6bf1db4320ec0c3f303be092b3 upstream.
+
+The document 'ACPI for Arm Components 1.0' defines the following
+_HID mappings:
+-'Prime cell UART (PL011)': ARMH0011
+-'SBSA UART': ARMHB000
+
+Use the sbsa-uart driver when a device is described with
+the 'ARMHB000' _HID.
+
+Note:
+PL011 devices currently use the sbsa-uart driver instead of the
+uart-pl011 driver. Indeed, PL011 devices are not bound to a clock
+in ACPI. It is not possible to change their baudrate.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
+Link: https://lore.kernel.org/r/20211109172248.19061-1-Pierre.Gondois@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/amba-pl011.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/tty/serial/amba-pl011.c
++++ b/drivers/tty/serial/amba-pl011.c
+@@ -2702,6 +2702,7 @@ MODULE_DEVICE_TABLE(of, sbsa_uart_of_mat
+
+ static const struct acpi_device_id sbsa_uart_acpi_match[] = {
+ { "ARMH0011", 0 },
++ { "ARMHB000", 0 },
+ {},
+ };
+ MODULE_DEVICE_TABLE(acpi, sbsa_uart_acpi_match);
net-qlogic-qlcnic-fix-a-null-pointer-dereference-in-qlcnic_83xx_add_rings.patch
siphash-use-_unaligned-version-by-default.patch
net-rds-correct-socket-tunable-error-in-rds_tcp_tune.patch
+parisc-fix-make-install-on-newer-debian-releases.patch
+vgacon-propagate-console-boot-parameters-before-calling-vc_resize.patch
+tty-serial-msm_serial-deactivate-rx-dma-for-polling-support.patch
+serial-pl011-add-acpi-sbsa-uart-match-id.patch
+serial-core-fix-transmit-buffer-reset-and-memleak.patch
--- /dev/null
+From 7492ffc90fa126afb67d4392d56cb4134780194a Mon Sep 17 00:00:00 2001
+From: Sven Eckelmann <sven@narfation.org>
+Date: Sat, 13 Nov 2021 13:10:50 +0100
+Subject: tty: serial: msm_serial: Deactivate RX DMA for polling support
+
+From: Sven Eckelmann <sven@narfation.org>
+
+commit 7492ffc90fa126afb67d4392d56cb4134780194a upstream.
+
+The CONSOLE_POLLING mode is used for tools like k(g)db. In this kind of
+setup, it is often sharing a serial device with the normal system console.
+This is usually no problem because the polling helpers can consume input
+values directly (when in kgdb context) and the normal Linux handlers can
+only consume new input values after kgdb switched back.
+
+This is not true anymore when RX DMA is enabled for UARTDM controllers.
+Single input values can no longer be received correctly. Instead following
+seems to happen:
+
+* on 1. input, some old input is read (continuously)
+* on 2. input, two old inputs are read (continuously)
+* on 3. input, three old input values are read (continuously)
+* on 4. input, 4 previous inputs are received
+
+This repeats then for each group of 4 input values.
+
+This behavior changes slightly depending on what state the controller was
+when the first input was received. But this makes working with kgdb
+basically impossible because control messages are always corrupted when
+kgdboc tries to parse them.
+
+RX DMA should therefore be off when CONSOLE_POLLING is enabled to avoid
+these kind of problems. No such problem was noticed for TX DMA.
+
+Fixes: 99693945013a ("tty: serial: msm: Add RX DMA support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sven Eckelmann <sven@narfation.org>
+Link: https://lore.kernel.org/r/20211113121050.7266-1-sven@narfation.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/msm_serial.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/tty/serial/msm_serial.c
++++ b/drivers/tty/serial/msm_serial.c
+@@ -611,6 +611,9 @@ static void msm_start_rx_dma(struct msm_
+ u32 val;
+ int ret;
+
++ if (IS_ENABLED(CONFIG_CONSOLE_POLL))
++ return;
++
+ if (!dma->chan)
+ return;
+
--- /dev/null
+From 3dfac26e2ef29ff2abc2a75aa4cd48fce25a2c4b Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Tue, 26 Oct 2021 00:26:22 +0200
+Subject: vgacon: Propagate console boot parameters before calling `vc_resize'
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 3dfac26e2ef29ff2abc2a75aa4cd48fce25a2c4b upstream.
+
+Fix a division by zero in `vgacon_resize' with a backtrace like:
+
+vgacon_resize
+vc_do_resize
+vgacon_init
+do_bind_con_driver
+do_unbind_con_driver
+fbcon_fb_unbind
+do_unregister_framebuffer
+do_register_framebuffer
+register_framebuffer
+__drm_fb_helper_initial_config_and_unlock
+drm_helper_hpd_irq_event
+dw_hdmi_irq
+irq_thread
+kthread
+
+caused by `c->vc_cell_height' not having been initialized. This has
+only started to trigger with commit 860dafa90259 ("vt: Fix character
+height handling with VT_RESIZEX"), however the ultimate offender is
+commit 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow
+retaking of the console").
+
+Said commit has added a call to `vc_resize' whenever `vgacon_init' is
+called with the `init' argument set to 0, which did not happen before.
+And the call is made before a key vgacon boot parameter retrieved in
+`vgacon_startup' has been propagated in `vgacon_init' for `vc_resize' to
+use to the console structure being worked on. Previously the parameter
+was `c->vc_font.height' and now it is `c->vc_cell_height'.
+
+In this particular scenario the registration of fbcon has failed and vt
+resorts to vgacon. Now fbcon does have initialized `c->vc_font.height'
+somehow, unlike `c->vc_cell_height', which is why this code did not
+crash before, but either way the boot parameters should have been copied
+to the console structure ahead of the call to `vc_resize' rather than
+afterwards, so that first the call has a chance to use them and second
+they do not change the console structure to something possibly different
+from what was used by `vc_resize'.
+
+Move the propagation of the vgacon boot parameters ahead of the call to
+`vc_resize' then. Adjust the comment accordingly.
+
+Fixes: 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console")
+Cc: stable@vger.kernel.org # v2.6.18+
+Reported-by: Wim Osterholt <wim@djo.tudelft.nl>
+Reported-by: Pavel V. Panteleev <panteleev_p@mcst.ru>
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2110252317110.58149@angie.orcam.me.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/console/vgacon.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/video/console/vgacon.c
++++ b/drivers/video/console/vgacon.c
+@@ -420,11 +420,17 @@ static void vgacon_init(struct vc_data *
+ struct uni_pagedir *p;
+
+ /*
+- * We cannot be loaded as a module, therefore init is always 1,
+- * but vgacon_init can be called more than once, and init will
+- * not be 1.
++ * We cannot be loaded as a module, therefore init will be 1
++ * if we are the default console, however if we are a fallback
++ * console, for example if fbcon has failed registration, then
++ * init will be 0, so we need to make sure our boot parameters
++ * have been copied to the console structure for vgacon_resize
++ * ultimately called by vc_resize. Any subsequent calls to
++ * vgacon_init init will have init set to 0 too.
+ */
+ c->vc_can_do_color = vga_can_do_color;
++ c->vc_scan_lines = vga_scan_lines;
++ c->vc_font.height = c->vc_cell_height = vga_video_font_height;
+
+ /* set dimensions manually if init != 0 since vc_resize() will fail */
+ if (init) {
+@@ -433,8 +439,6 @@ static void vgacon_init(struct vc_data *
+ } else
+ vc_resize(c, vga_video_num_columns, vga_video_num_lines);
+
+- c->vc_scan_lines = vga_scan_lines;
+- c->vc_font.height = c->vc_cell_height = vga_video_font_height;
+ c->vc_complement_mask = 0x7700;
+ if (vga_512_chars)
+ c->vc_hi_font_mask = 0x0800;
projects / thirdparty / kernel / stable-queue.git / commitdiff
