Doing any kind of power management for kernel console is really bad idea.

First of all, it runs in poll and atomic mode. This fact attaches a limitation
on the functions that might be called. For example, pm_runtime_get_sync() might
sleep and thus can't be used. This call needs, for example, to bring the device
to powered on state on the system, where the power on sequence may require
on-atomic operations, such as Intel Cherrytrail with ACPI enumerated UARTs.
That said, on ACPI enabled platforms it might even call firmware for a job.

On the other hand pm_runtime_get() doesn't guarantee that device will become
powered on fast enough.

Besides that, imagine the case when console is about to print a kernel Oops and
it's powered off. In such an emergency case calling the complex functions is
not the best what we can do, taking into consideration that user wants to see
at least something of the last kernel word before it passes away.

Here we modify the 8250 console code to prevent runtime power management.

Note, there is a behaviour change for OMAP boards. It will require to detach
kernel console to become idle.

Link: https://lists.openwall.net/linux-kernel/2018/09/29/65Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200217114016.49856-6-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In the future we would like to disable power management on the serial devices
used as kernel consoles to avoid weird behaviour in some cases. However,
disabling PM may prevent system to go to deep sleep states, which in its turn
leads to the higher power consumption.

Tony Lindgren proposed a work around, i.e. allow user to detach such consoles
to make PM working again. In case user wants to see what's going on, it also
provides a mechanism to attach console back.

Link: https://lists.openwall.net/linux-kernel/2018/09/29/65Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200217114016.49856-3-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'for-5.7-console-exit' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk into tty-next

We need the console patches in here as well for futher work from Andy.

* 'for-5.7-console-exit' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk:
  console: Introduce ->exit() callback
  console: Don't notify user space when unregister non-listed console
  console: Avoid positive return code from unregister_console()
  console: Drop misleading comment
  console: Use for_each_console() helper in unregister_console()
  console: Drop double check for console_drivers being non-NULL
  console: Don't perform test for CON_BRL flag
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 175b558d.

When the user configures a kernel without support for Samsung SoCs, it
makes no sense to ask the user about enabling "Samsung SoC serial
support", as Samsung serial ports can only be found on Samsung SoCs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200306102301.16870-1-geert+renesas@glider.beSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We should validate if the 'sup' is NULL or not before freeing DMA
memory, to fix below warning.

"drivers/tty/serial/sprd_serial.c:1141 sprd_remove()
 error: we previously assumed 'sup' could be null (see line 1132)"

Fixes: f4487db5 ("serial: sprd: Add DMA mode support")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Lanqing Liu <liuhhome@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/e2bd92691538e95b04a2c2a728f3292e1617018f.1584325957.git.liuhhome@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The function sprd_console_setup() would be called from .probe() which can
be called after freeing __init functions, for example the .probe() would
return -EPROBE_DEFER since it depends on clock modules.
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200316101930.9962-3-zhang.lyra@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The SPRD serial driver need to know which serial port would be used as
console in an early period during initialization, the purpose is to
keep the console port alive as possible even if there's some error
caused by no clock configured under serial devicetree nodes. But with
the patch [1], the console port couldn't be identified if missing
console command line.

So this patch adds using another interface to do check by reading
stdout-path.

[1] https://lore.kernel.org/lkml/20190826072929.7696-4-zhang.lyra@gmail.com/Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20200316101930.9962-2-zhang.lyra@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Shift cases one level left. This makes the code more readable and some
lines need not wrap anymore.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200316065911.11024-3-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We have a helper called rounddown for these modulo computations. So use
it.

No functional change intended and "objdump -d" proves that.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200316065911.11024-2-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of awkward ternary operator with comparison, use simple min()
for blankinterval and vesa_off_interval.

No functional change intended and "objdump -d" proves that.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20200316065911.11024-1-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

As Joe suggests, dynamic debug can print module name and line number
along with message. So remove __FILE__ and __LINE__ from all those
pr_debug calls.

Out of curiosity, I measured the savings, 200 bytes of code are gone.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Suggested-by: Joe Perches <joe@perches.com>
Link: https://lore.kernel.org/r/20200316064910.4941-1-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The merge commit cb05c6c8 (Merge 5.6-rc5 into tty-next) introduced a
double lock to set_selection_kernel. vc_sel.lock is locked both in
set_selection_kernel and its callee __set_selection_kernel now.

Remove the latter.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20200316064544.4799-1-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The geni serial driver's shutdown code had a special case to call
console_stop().  Grepping through the code, it was the only serial
driver doing something like this (the only other caller of
console_stop() was in serial_core.c).

As far as I can tell there's no reason to call console_stop() in the
geni code.  ...and a good reason _not_ to call it.  Specifically if
you have an agetty running on the same serial port as the console then
killing the agetty kills your console and if you start the agetty
again the console doesn't come back.

Fixes: c4f52879 ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200313134635.2.I3648fac6c98b887742934146ac2729ecb7232eb1@changeidSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

On a board using qcom_geni_serial I found that I could no longer
interact with kdb if I got a crash after the "agetty" running on the
same serial port was killed.  This meant that various classes of
crashes that happened at reboot time were undebuggable.

Reading through the code, I couldn't figure out why qcom_geni_serial
felt the need to run so much code at port shutdown time.  All we need
to do is disable the interrupt.

After I make this change then a hardcoded kgdb_breakpoint in some late
shutdown code now allows me to interact with the debugger.  I also
could freely close / re-open the port without problems.

Fixes: c4f52879 ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200313134635.1.Icf54c533065306b02b880c46dfd401d8db34e213@changeidSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The vc_cons_allocated() checks in vt_ioctl() and vt_compat_ioctl() are
unnecessary because they can only be reached by calling ioctl() on an
open tty, which implies the corresponding virtual console is allocated.

And even if the virtual console *could* be freed concurrently, then
these checks would be broken since they aren't done under console_lock,
and the vc_data is dereferenced before them anyway.

So, remove these unneeded checks to avoid confusion.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20200224080326.295046-1-ebiggers@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The might_sleep() in do_con_write() is redundant because console_lock()
already contains might_sleep().  Remove it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20200224073450.292892-1-ebiggers@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Refactor uart_unlock_and_check_sysrq() to:

  - explicitly show that we release a port lock which makes
    static analyzers happy:

CHECK   drivers/tty/serial/serial_core.c
.../serial_core.c:3290:17: warning: context imbalance in 'uart_unlock_and_check_sysrq' - unexpected unlock

  - use flags instead of irqflags to avoid confusion with IRQ flags

  - provide one return point

  - be more compact
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Link: https://lore.kernel.org/r/20200310174337.74109-4-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use uart_console() helper in SysRq code instead of open coded variant.
This eliminates the conditional entirely for SERIAL_CORE_CONSOLE=n case.
While here, refactor the conditional to be more compact.
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200310174337.74109-3-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It is useful to see on the serial console the magic sequence itself
to enable SysRq without rummaging source code.
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200310174337.74109-2-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Compiler is not happy about using ARRAY_SIZE() in comparison to smaller type:

  CC      drivers/tty/serial/serial_core.o
.../serial_core.c: In function ‘uart_try_toggle_sysrq’:
.../serial_core.c:3222:24: warning: comparison is always false due to limited range of data type [-Wtype-limits]
 3222 |  if (++port->sysrq_seq < (ARRAY_SIZE(sysrq_toggle_seq) - 1)) {
      |                        ^

Looking at the code it appears that there is an additional weirdness,
i.e. use ARRAY_SIZE() against simple string literal. Yes, the idea probably
was to allow '\0' in the sequence, but it's impractical: kernel configuration
won't accept it to begin with followed by a comment about '\0' before
comparison in question.

Drop all these by switching to strlen() and convert code accordingly.

Note, GCC seems clever enough to calculate string length at compile time.

Fixes: 68af4317 ("serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE")
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200310174337.74109-1-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To fix the RX cancel command failure, rx_fifo buffer needs to be
flushed in stop_rx() by calling handle_rx().In handle_rx() the data
in rx_fifo buffer is read and then dropped, not sent to upper layers.

If set_termios is called before startup, by this time memory is not
allocated to port->rx_fifo buffer, which leads to a NULL pointer
dereference.

To avoid this NULL pointer dereference allocate memory to port->rx_fifo
in probe itself.
Signed-off-by: satya priya <skakit@codeaurora.org>
Reported-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1583477228-32231-2-git-send-email-skakit@codeaurora.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This driver for the Intel MID never seems to have been properly
integrated upstream: the platform data in <linux/spi/ifx_modem.h>
is not used anywhere in the kernel and haven't been since it was
merged into the kernel in 2010.

There might be out-of-tree users, so I don't want to delete the
driver, but I will refactor it to use GPIO descriptors, which
means that out-of-tree users will need to adapt.

There are several examples in the kernel of how to provide the
resources necessary for using GPIO descriptors to pass in the
GPIO lines, for the MID platform in particular, it will suffice
to inspect the code in files like:
arch/x86/platform/intel-mid/device_libs/platform_bt.c

This refactoring transfers all GPIOs in the driver, including
a hard-coded "PMU reset" in the driver to use GPIO descriptors
instead.

The following named GPIO descriptors need to be supplied:
- reset
- power
- mrdy
- srdy
- rst_out
- pmu_reset

Cc: Russ Gorby <russ.gorby@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200311083131.693908-2-linus.walleij@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The &spi->dev is used so many times that the code gets
visibly better by introducing a simple dev helper variable.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200311083131.693908-1-linus.walleij@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The LS1028A has six LPUART controllers. Add the nodes.

This was tested on a custom board.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200307091302.14881-2-michael@walle.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the LS1028A SoC compatibility string to the lpuart devicetree
bindings documentation.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200307091302.14881-1-michael@walle.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a early_console_setup() for the LS1028A SoC with 32bit, little
endian access. If the bootloader does a fixup of the clock-frequency
node the baudrate divisor register will automatically be set.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-5-michael@walle.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The LS1028A uses little endian register access and has a different FIFO
size encoding.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-4-michael@walle.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the correct device to request the DMA mapping. Otherwise the IOMMU
doesn't get the mapping and it will generate a page fault.

The error messages look like:
[   19.012140] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xbbfff800, fsynr=0x3e0021, cbfrsynra=0x828, cb=9
[   19.023593] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xbbfff800, fsynr=0x3e0021, cbfrsynra=0x828, cb=9

This was tested on a custom board with a LS1028A SoC.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-3-michael@walle.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The DMA channel might not be available at probe time. This is esp. the
case if the DMA controller has an IOMMU mapping.

There is also another caveat. If there is no DMA controller at all,
dma_request_chan() will also return -EPROBE_DEFER. Thus we cannot test
for -EPROBE_DEFER in probe(). Otherwise the lpuart driver will fail to
probe if, for example, the DMA driver is not enabled in the kernel
configuration.

To workaround this, we request the DMA channel in _startup(). Other
serial drivers do it the same way.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200306214433.23215-2-michael@walle.ccSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To make it more obvious what almost everyone wants to set here.

Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Joe Perches <joe@perches.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Vasiliy Khoruzhick <vasilykh@arista.com>
Cc: linux-serial@vger.kernel.org
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dmitry Safonov <dima@arista.com>
Link: https://lore.kernel.org/r/20200306153156.579921-1-dima@arista.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use uart_console() helper in instead of open coded variant.

Note, SERIAL_CORE_CONSOLE is selected by SERIAL_ATMEL_CONSOLE,
thus no functional changes expected.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Richard Genoud <richard.genoud@gmail.com>
Link: https://lore.kernel.org/r/20200310133057.86840-1-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use uart_console() helper in instead of open coded variant.

Note, SERIAL_CORE_CONSOLE is selected by SERIAL_PIC32_CONSOLE,
thus no functional changes expected.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200311090027.64441-1-andriy.shevchenko@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SiFive's UART has a software controller clock divider that produces the
final baud rate clock.  Whenever the clock that drives the UART is
changed this divider must be updated accordingly, and given that these
two events are controlled by software they cannot be done atomically.
During the period between updating the UART's driving clock and internal
divider the UART will transmit a different baud rate than what the user
has configured, which will probably result in a corrupted transmission
stream.

The SiFive UART has a FIFO, but due to an issue with the programming
interface there is no way to directly determine when the UART has
finished transmitting.  We're essentially restricted to dead reckoning
in order to figure that out: we can use the FIFO's TX busy register to
figure out when the last frame has begun transmission and just delay for
a long enough that the last frame is guaranteed to get out.

As far as the actual implementation goes: I've modified the existing
existing clock notifier function to drain both the FIFO and the shift
register in on PRE_RATE_CHANGE.  As far as I know there is no hardware
flow control in this UART, so there's no good way to ask the other end
to stop transmission while we can't receive (inserting software flow
control messages seems like a bad idea here).
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Tested-by: Yash Shah <yash.shah@sifive.com>
Link: https://lore.kernel.org/r/20200307042637.83728-1-palmer@dabbelt.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We need the vt fixes in here and it resolves a merge issue with
drivers/tty/vt/selection.c
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull ARM SoC fixes from Olof Johansson:
 "We've been accruing these for a couple of weeks, so the batch is a bit
  bigger than usual.

  Largest delta is due to a led-bl driver that is added -- there was a
  miscommunication before the merge window and the driver didn't make it
  in. Due to this, the platforms needing it regressed. At this point, it
  seemed easier to add the new driver than unwind the changes.

  Besides that, there are a handful of various fixes:

   - AMD tee memory leak fix

   - A handful of fixlets for i.MX SCU communication

   - A few maintainers woke up and realized DEBUG_FS had been missing
     for a while, so a few updates of that.

  ... and the usual collection of smaller fixes to various platforms"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (37 commits)
  ARM: socfpga_defconfig: Add back DEBUG_FS
  arm64: dts: socfpga: agilex: Fix gmac compatible
  ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FS
  arm64: dts: meson: fix gxm-khadas-vim2 wifi
  arm64: dts: meson-sm1-sei610: add missing interrupt-names
  ARM: meson: Drop unneeded select of COMMON_CLK
  ARM: dts: bcm2711: Add pcie0 alias
  ARM: dts: bcm283x: Add missing properties to the PWR LED
  tee: amdtee: fix memory leak in amdtee_open_session()
  ARM: OMAP2+: Fix compile if CONFIG_HAVE_ARM_SMCCC is not set
  arm: dts: dra76x: Fix mmc3 max-frequency
  ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes
  bus: ti-sysc: Fix 1-wire reset quirk
  ARM: dts: r8a7779: Remove deprecated "renesas, rcar-sata" compatible value
  soc: imx-scu: Align imx sc msg structs to 4
  firmware: imx: Align imx_sc_msg_req_cpu_start to 4
  firmware: imx: scu-pd: Align imx sc msg structs to 4
  firmware: imx: misc: Align imx sc msg structs to 4
  firmware: imx: scu: Ensure sequential TX
  ARM: dts: imx7-colibri: Fix frequency for sd/mmc
  ...

Pull EDAC fix from Borislav Petkov:
 "Error reporting fix for synopsys_edac: do not overwrite partial
  decoded error message (Sherry Sun)"

* tag 'edac_urgent-2020-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
  EDAC/synopsys: Do not print an error with back-to-back snprintf() calls

Pull char/misc fixes from Greg KH:
 "Here are four small char/misc driver fixes for reported issues for
  5.6-rc5.

  These fixes are:

   - binder fix for a potential use-after-free problem found (took two
     tries to get it right)

   - interconnect core fix

   - altera-stapl driver fix

  All four of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  binder: prevent UAF for binderfs devices II
  interconnect: Handle memory allocation errors
  altera-stapl: altera_get_note: prevent write beyond end of 'key'
  binder: prevent UAF for binderfs devices

Pull driver core and debugfs fixes from Greg KH:
 "Here are four small driver core / debugfs patches for 5.6-rc3:

   - debugfs api cleanup now that all debugfs_create_regset32() callers
     have been fixed up. This was waiting until after the -rc1 merge as
     these fixes came in through different trees

   - driver core sync state fixes based on reports of minor issues found
     in the feature

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

* tag 'driver-core-5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  driver core: Skip unnecessary work when device doesn't have sync_state()
  driver core: Add dev_has_sync_state()
  driver core: Call sync_state() even if supplier has no consumers
  debugfs: remove return value of debugfs_create_regset32()

Pull tty/serial fixes from Greg KH:
 "Here are some small tty/serial fixes for 5.6-rc5

  Just some small serial driver fixes, and a vt core fixup, full details
  are:

   - vt fixes for issues found by syzbot

   - serdev fix for Apple boxes

   - fsl_lpuart serial driver fixes

   - MAINTAINER update for incorrect serial files

   - new device ids for 8250_exar driver

   - mvebu-uart fix

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

* tag 'tty-5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  tty: serial: fsl_lpuart: free IDs allocated by IDA
  Revert "tty: serial: fsl_lpuart: drop EARLYCON_DECLARE"
  serdev: Fix detection of UART devices on Apple machines.
  MAINTAINERS: Add missed files related to Synopsys DesignWare UART
  serial: 8250_exar: add support for ACCES cards
  tty:serial:mvebu-uart:fix a wrong return
  vt: selection, push sel_lock up
  vt: selection, push console lock down