After some unsuccessful attempts to use sysrq over console, figured
out that port->has_sysrq should likely be enabled, as per other
architectures, this when CONFIG_SERIAL_MCF_CONSOLE is also enabled.

Tested some magic sysrq commands (h, p, t, b), they works now
properly. Commands works inside 5 secs after BREAK is sent, as
expected.

Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Link: https://lore.kernel.org/r/20201002140545.477481-1-angelo.dureghello@timesys.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add handling of magic sysrq keys when using dma/edma.

Tested by sending BREAK followed by a sysrq command inside
a 5 secs time window, by:

echo 1 > /proc/sys/kernel/sysrq

BREAK + h, t, e, b, c

Tested also sending a command after 5 secs after BREAK, that's
properly ignored.

Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Link: https://lore.kernel.org/r/20201004161144.1307174-1-angelo.dureghello@timesys.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We don't need to call vc->vc_sw->con_set_origin() from set_origin()
if it is no-op.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: https://lore.kernel.org/r/20200915000019.3422-3-penguin-kernel@I-love.SAKURA.ne.jp


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

All slots in sysrq_key_table[] are either used, reserved or at least
commented with their intended use. This patch adds capital letter versions
available, which means adding 26 more entries.

For already existing SysRq operations the user presses Alt-SysRq-<key>, and
for the newly added ones Alt-Shift-SysRq-<key>.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20200818112825.6445-2-andrzej.p@collabora.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, the RX interrupt logic uses the RXEMPTY interrupt, with the
RXEMPTYINV bit set, which means we get an RX interrupt as soon as the
RX FIFO is non-empty.

However, with the MAX310X having a FIFO of 128 bytes, this makes very
poor use of the FIFO: we trigger an interrupt as soon as the RX FIFO
has one byte, which means a lot of interrupts, each only collecting a
few bytes from the FIFO, causing a significant CPU load.

Instead this commit relies on two other RX interrupt events:

 - MAX310X_IRQ_RXFIFO_BIT, which triggers when the RX FIFO has reached
   a certain threshold, which we define to be half of the FIFO
   size. This ensure we get an interrupt before the RX FIFO fills up.

 - MAX310X_LSR_RXTO_BIT, which triggers when the RX FIFO has received
   some bytes, and then no more bytes are received for a certain
   time. Arbitrarily, this time is defined to the time is takes to
   receive 4 characters.

On a Microchip SAMA5D3 platform that is receiving 20 bytes every 16ms
over one MAX310X UART, this patch has allowed to reduce the CPU
consumption of the interrupt handler thread from ~25% to 6-7%.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Link: https://lore.kernel.org/r/20201001074415.349739-1-thomas.petazzoni@bootlin.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It has been discovered that there is a potential deadlock between
the clock-change-notifier thread and the UART port suspending one:

   CPU0 (suspend CPU/UART)   CPU1 (update clock)
            ----                    ----
   lock(&port->mutex);
                             lock((work_completion)(&data->clk_work));
                             lock(&port->mutex);
   lock((work_completion)(&data->clk_work));

   *** DEADLOCK ***

The best way to fix this is to eliminate the CPU0
port->mutex/work-completion scenario. So we suggest to register and
unregister the clock-notifier during the DW APB UART port probe/remove
procedures, instead of doing that at the points of the port
startup/shutdown.

Link: https://lore.kernel.org/linux-serial/f1cd5c75-9cda-6896-a4e2-42c5bfc3f5c3@redhat.com

Fixes: cc816969

 ("serial: 8250_dw: Fix common clocks usage race condition")
Reported-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200923161950.6237-4-Sergey.Semin@baikalelectronics.ru


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It is erroneous to update the TTY port baud rate if it hasn't been
initialized yet, because in that case the TTY struct isn't set. So there
is no termios structure to get and re-calculate the baud if the current
baud can't be reached. Let's skip the baud rate update then until the port
is fully initialized.

Note the update UART clock method still sets the uartclk member with a new
ref clock value even if the port is turned off. The new UART ref clock
rate will be used later on the port starting up procedure.

Fixes: 868f3ee6

 ("serial: 8250: Add 8250 port clock update method")
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200923161950.6237-3-Sergey.Semin@baikalelectronics.ru


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It has been a mistake to add the MCR register RTS/DTS fields setting in
the generic method of the UART reference clock update. There is no point
in asserting these lines at that procedure. Just discard the
serial8250_out_MCR() mathod invocation from there then.

Fixes: 868f3ee6

 ("serial: 8250: Add 8250 port clock update method")
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200923161950.6237-2-Sergey.Semin@baikalelectronics.ru


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The IPG clock is disabled at the end of imx_uart_shutdown(); we really
don't want to run any IRQ handlers after this point.

At least on i.MX8MN, the UART will happily continue to generate interrupts
even with its clocks disabled, but in this state, all register writes are
ignored (which will cause the shadow registers to differ from the actual
register values, resulting in all kinds of weirdness).

In a transfer without DMA, this could lead to the following sequence of
events:

- The UART finishes its transmission while imx_uart_shutdown() is run,
  triggering the TXDC interrupt (we can trigger this fairly reliably by
  writing a single byte to the TTY and closing it right away)
- imx_uart_shutdown() finishes, disabling the UART clocks
- imx_uart_int() -> imx_uart_transmit_buffer() -> imx_uart_stop_tx()

imx_uart_stop_tx() should now clear UCR4_TCEN to disable the TXDC
interrupt, but this register write is ineffective. This results in an
interrupt storm.

To disable all interrupts in the same place, and to avoid setting UCR4
twice, clearing UCR4_OREN is moved below del_timer_sync() as well; this
should be harmless.

Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://lore.kernel.org/r/20200925082412.12960-1-matthias.schiffer@ew.tq-group.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This is the port of the commit db1b5bc0

 ("serial: 8250: Fix TX
interrupt handling condition") to the 8250_fsl irq handling logic.

Interrupt handler checked THRE bit (transmitter holding register
empty) in LSR to detect if TX fifo is empty.
In case when there is only receive interrupts the TX handling
got called because THRE bit in LSR is set when there is no
transmission (FIFO empty). TX handling caused TX stop, which in
RS-485 half-duplex mode actually resets receiver FIFO. This is not
desired during reception because of possible data loss.

The fix is to check if THRI is set in IER in addition of the TX
fifo status. THRI in IER is set when TX is started and cleared
when TX is stopped.
This ensures that TX handling is only called when there is really
transmission on going and an interrupt for THRE and not when there
are only RX interrupts.

Signed-off-by: Andrij Abyzov <aabyzov@slb.com>
Link: https://lore.kernel.org/r/20200928144127.87156-1-aabyzov@slb.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Issuing a magic-sysrq via the PL011 causes the following lockdep splat,
which is easily reproducible under QEMU:

  | sysrq: Changing Loglevel
  | sysrq: Loglevel set to 9
  |
  | ======================================================
  | WARNING: possible circular locking dependency detected
  | 5.9.0-rc7 #1 Not tainted
  | ------------------------------------------------------
  | systemd-journal/138 is trying to acquire lock:
  | ffffab133ad950c0 (console_owner){-.-.}-{0:0}, at: console_lock_spinning_enable+0x34/0x70
  |
  | but task is already holding lock:
  | ffff0001fd47b098 (&port_lock_key){-.-.}-{2:2}, at: pl011_int+0x40/0x488
  |
  | which lock already depends on the new lock.

  [...]

  |  Possible unsafe locking scenario:
  |
  |        CPU0                    CPU1
  |        ----                    ----
  |   lock(&port_lock_key);
  |                                lock(console_owner);
  |                                lock(&port_lock_key);
  |   lock(console_owner);
  |
  |  *** DEADLOCK ***

The issue being that CPU0 takes 'port_lock' on the irq path in pl011_int()
before taking 'console_owner' on the printk() path, whereas CPU1 takes
the two locks in the opposite order on the printk() path due to setting
the "console_owner" prior to calling into into the actual console driver.

Fix this in the same way as the msm-serial driver by dropping 'port_lock'
before handling the sysrq.

Cc: <stable@vger.kernel.org> # 4.19+
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20200811101313.GA6970@willie-the-truck


Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20200930120432.16551-1-will@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The watermark is set to 1, so we need to input two chars to trigger RDRF
using the original logic. With the new logic, we could always get the
char when there is data in FIFO.

Suggested-by: Fugang Duan <fugang.duan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20200929095509.21680-1-peng.fan@nxp.com


Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The 2nd and 3rd parameter were wrongly used, and cause kernel abort when
doing kgdb debug.

Fixes: 1da17d7c

 ("tty: serial: fsl_lpuart: Use appropriate lpuart32_* I/O funcs")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20200929091920.22612-1-peng.fan@nxp.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

For QUP IP versions 2.5 and above the oversampling rate is
halved from 32 to 16.

Commit ce734600 ("tty: serial: qcom_geni_serial: Update
the oversampling rate") is pushed to handle this scenario.
But the existing logic is failing to classify QUP Version 3.0
into the correct group ( 2.5 and above).

As result Serial Engine clocks are not configured properly for
baud rate and garbage data is sampled to FIFOs from the line.

So, fix the logic to detect QUP with versions 2.5 and above.

Fixes: ce734600

 ("tty: serial: qcom_geni_serial: Update the oversampling rate")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Paras Sharma <parashar@codeaurora.org>
Reviewed-by: Akash Asthana <akashast@codeaurora.org>
Link: https://lore.kernel.org/r/1601445926-23673-1-git-send-email-parashar@codeaurora.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There's a warning shows that 'ret' becomes an unused variable
after simplify the return expression of mvebu_uart_probe(). So
remove it.

Fixes: b6353702

 ("serial: mvebu-uart: simplify the return expression of mvebu_uart_probe()")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://lore.kernel.org/r/20200929085651.158283-1-miaoqinglang@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

syzbot is reporting UAF/OOB read at bit_putcs()/soft_cursor() [1][2], for
vt_resizex() from ioctl(VT_RESIZEX) allows setting font height larger than
actual font height calculated by con_font_set() from ioctl(PIO_FONT).
Since fbcon_set_font() from con_font_set() allocates minimal amount of
memory based on actual font height calculated by con_font_set(),
use of vt_resizex() can cause UAF/OOB read for font data.

VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what
comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX.

  #define VT_RESIZE   0x5609 /* set kernel's idea of screensize */
  #define VT_RESIZEX  0x560A /* set kernel's idea of screensize + more */

So far we are not aware of syzbot reports caused by setting non-zero value
to v_vlin parameter. But given that it is possible that nobody is using
VT_RESIZEX, we can try removing support for v_clin and v_vlin parameters.

Therefore, this patch effectively makes VT_RESIZEX behave like VT_RESIZE,
with emitting a message if somebody is still using v_clin and/or v_vlin
parameters.

[1] https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837
[2] https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3



Reported-by: syzbot <syzbot+b308f5fd049fbbc6e74f@syzkaller.appspotmail.com>
Reported-by: syzbot <syzbot+16469b5e8e5a72e9131e@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/4933b81b-9b1a-355b-df0e-9b31e8280ab9@i-love.sakura.ne.jp


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Simplify the return expression.

Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://lore.kernel.org/r/20200921131105.93177-1-miaoqinglang@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

aarch64-linux-gnu-ld: drivers/tty/serial/imx_earlycon.o: in function `imx_uart_console_early_write':
imx_earlycon.c:(.text+0x84): undefined reference to `uart_console_write'

The driver uses the uart_console_write(), but SERIAL_CORE_CONSOLE is not
selected, so uart_console_write is not defined, then we get the error.
Fix this by selecting SERIAL_CORE_CONSOLE.

Fixes: 699cc4df

 ("tty: serial: imx: add imx earlycon driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20200919063240.2754965-1-yangyingliang@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

aarch64-linux-gnu-ld: drivers/tty/hvc/hvc_dcc.o: in function `dcc_early_write':
hvc_dcc.c:(.text+0x164): undefined reference to `uart_console_write'

The driver uses the uart_console_write(), but SERIAL_CORE_CONSOLE is not
selected, so uart_console_write is not defined, then we get the error.
Fix this by selecting SERIAL_CORE_CONSOLE.

Fixes: d1a1af2c

 ("hvc: dcc: Add earlycon support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20200919063535.2809707-1-yangyingliang@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sg_init_table zeroes its first argument, so the allocation of that argument
doesn't have to.

the semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/

)

// <smpl>
@@
expression x,n,flags;
@@

x =
- kcalloc
+ kmalloc_array
  (n,sizeof(struct scatterlist),flags)
...
sg_init_table(x,n)
// </smpl>

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>

Link: https://lore.kernel.org/r/1600601186-7420-2-git-send-email-Julia.Lawall@inria.fr


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible HSCIF ports,
so document the SoC specific bindings.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/1594230511-24790-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RZ/G2H (R8A774E1) SoC also has the R-Car gen3 compatible SCIF ports,
so document the SoC specific bindings.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/1594230511-24790-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge ba31128384dfd ("Merge tag 'libnvdimm-fixes-5.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm"

) into tty-next

We need the dax build fix in here so that our builds do not keep
breaking.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull libnvdimm fix from Dan Williams:
 "Fix compilation for the new dax_supported() exported helper"

* tag 'libnvdimm-fixes-5.9-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  dax: Fix compilation for CONFIG_DAX && !CONFIG_FS_DAX

dax_supported() is defined whenever CONFIG_DAX is enabled. So dummy
implementation should be defined only in !CONFIG_DAX case, not in
!CONFIG_FS_DAX case.

Fixes: e2ec5128

 ("dm: Call proper helper to determine dax support")
Cc: <stable@vger.kernel.org>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

We need the tty/serial fixes in here and this resolves a merge issue in
the 8250 driver.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull syscall tracing fix from Borislav Petkov:
 "Fix the seccomp syscall rewriting so that trace and audit see the
  rewritten syscall number, from Kees Cook"

* tag 'core_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  core/entry: Report syscall correctly for trace and audit

Pull objtool fix from Borislav Petkov:
 "Fix noreturn detection for ignored sibling functions (Josh Poimboeuf)"

* tag 'objtool_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  objtool: Fix noreturn detection for ignored functions

Pull locking fixes from Borislav Petkov:
 "Two fixes from the locking/urgent pile:

   - Fix lockdep's detection of "USED" <- "IN-NMI" inversions (Peter
     Zijlstra)

   - Make percpu-rwsem operations on the semaphore's ->read_count
     IRQ-safe because it can be used in an IRQ context (Hou Tao)"

* tag 'locking_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/percpu-rwsem: Use this_cpu_{inc,dec}() for read_count
  locking/lockdep: Fix "USED" <- "IN-NMI" inversions

Pull EFI fix from Borislav Petkov:
 "Ensure that the EFI bootloader control module only probes successfully
  on systems that support the EFI SetVariable runtime service"

[ Tag and commit from Ard Biesheuvel, forwarded by Borislav ]

* tag 'efi-urgent-for-v5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: efibc: check for efivars write capability

Pull x86 fixes from Borislav Petkov:

 - A defconfig fix (Daniel Díaz)

 - Disable relocation relaxation for the compressed kernel when not
   built as -pie as in that case kernels built with clang and linked
   with LLD fail to boot due to the linker optimizing some instructions
   in non-PIE form; the gory details in the commit message (Arvind
   Sankar)

 - A fix for the "bad bp value" warning issued by the frame-pointer
   unwinder (Josh Poimboeuf)

* tag 'x86_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/unwind/fp: Fix FP unwinding in ret_from_fork
  x86/boot/compressed: Disable relocation relaxation
  x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig

Pull libnvdimm fixes from Dan Williams:
 "A handful of fixes to address a string of mistakes in the mechanism
  for device-mapper to determine if its component devices are dax
  capable.

   - Fix an original bug in device-mapper table reference counting when
     interrogating dax capability in the component device. This bug was
     hidden by the following bug.

   - Fix device-mapper to use the proper helper (dax_supported() instead
     of the leaf helper generic_fsdax_supported()) to determine dax
     operation of a stacked block device configuration. The original
     implementation is only valid for one level of dax-capable block
     device stacking. This bug was discovered while fixing the below
     regression.

   - Fix an infinite recursion regression introduced by broken attempts
     to quiet the generic_fsdax_supported() path and make it bail out
     before logging "dax capability not found" errors"

* tag 'libnvdimm-fixes-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  dax: Fix stack overflow when mounting fsdax pmem device
  dm: Call proper helper to determine dax support
  dm/dax: Fix table reference counts

Pull RISC-V fixes from Palmer Dabbelt:

 - A fix for a lockdep issue to avoid an asserting triggering during
   early boot. There shouldn't be any incorrect behavior as the system
   isn't concurrent at the time.

 - The addition of a missing fence when installing early fixmap
   mappings.

 - A corretion to the K210 device tree's interrupt map.

 - A fix for M-mode timer handling on the K210.

* tag 'riscv-for-linus-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  RISC-V: Resurrect the MMIO timer implementation for M-mode systems
  riscv: Fix Kendryte K210 device tree
  riscv: Add sfence.vma after early page table changes
  RISC-V: Take text_mutex in ftrace_init_nop()

Pull USB/Thunderbolt fixes from Greg KH:
 "Here are some small USB and one Thunderbolt driver fixes.

  Nothing major at all, just some fixes for reported issues, and a quirk
  addition:

   - typec fixes

   - UAS disconnect fix

   - usblp race fix

   - ehci-hcd modversions build fix

   - ignore wakeup quirk table addition

   - thunderbolt DROM read fix

  All of these have been in linux-next with no reported issues"

* tag 'usb-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usblp: fix race between disconnect() and read()
  ehci-hcd: Move include to keep CRC stable
  usb: typec: intel_pmc_mux: Handle SCU IPC error conditions
  USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebook
  USB: UAS: fix disconnect by unplugging a hub
  usb: typec: ucsi: Prevent mode overrun
  usb: typec: ucsi: acpi: Increase command completion timeout value
  thunderbolt: Retry DROM read once if parsing fails

Pull tty/serial/fbcon fixes from Greg KH:
 "Here are some small tty/serial and one more fbcon fix.

  They include:

   - serial core locking regression fixes

   - new device ids for 8250_pci driver

   - fbcon fix for syzbot found issue

  All have been in linux-next with no reported issues"

* tag 'tty-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  fbcon: Fix user font detection test at fbcon_resize().
  serial: 8250_pci: Add Realtek 816a and 816b
  serial: core: fix console port-lock regression
  serial: core: fix port-lock initialisation

Pull EDAC fixes from Borislav Petkov:
 "Two fixes for resulting from CONFIG_DEBUG_TEST_DRIVER_REMOVE=y
  experiments:

   - complete a previous fix to reset a local structure containing
     scanned system data properly so that the driver rescans, as it
     should, on a second load.

   - address a refcount underflow due to not paying attention to the
     driver whitelest on unregister"

* tag 'edac_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
  EDAC/ghes: Check whether the driver is on the safe list correctly
  EDAC/ghes: Clear scanned data on unload

Pull input fixes from Dmitry Torokhov:
 "Just a couple of driver quirks"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: trackpoint - add new trackpoint variant IDs
  Input: i8042 - add Entroware Proteus EL07R4 to nomux and reset lists

Sedat Dilek pointed out some silly comment typo issues.

Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'kbuild-fixes-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:
 "Fix qconf warnings and revive help message"

* tag 'kbuild-fixes-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  kconfig: qconf: revive help message in the info view
  kconfig: qconf: fix incomplete type 'struct gstr' warning
  kconfig: qconf: use delete[] instead of delete to free array (again)