linux-stable.git/drivers/tty/serial/Kconfig, branch linux-5.18.y

tty: serial: samsung: Add ARTPEC-8 support

2022-03-18T12:29:05+00:00

Add support for the UART block on the ARTPEC-8 SoC.  This is closely
related to the variants used on the Exynos chips.  The register layout
is identical to Exynos850 et al but the fifo size is different (64 bytes
in each direction for all instances).

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Vincent Whitchurch 
Link: https://lore.kernel.org/r/20220311094515.3223023-3-vincent.whitchurch@axis.com
Signed-off-by: Greg Kroah-Hartman

tty: serial: bcm63xx: use more precise Kconfig symbol

2022-03-18T12:17:33+00:00

Patches lowering SERIAL_BCM63XX dependencies led to a discussion and
documentation change regarding "depends" usage. Adjust Kconfig entry to
match current guidelines. Make this symbol available for relevant
architectures only.

Cc: Geert Uytterhoeven 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Florian Fainelli 
Signed-off-by: Rafał Miłecki 
Ref: f35a07f92616 ("tty: serial: bcm63xx: lower driver dependencies")
Ref: 18084e435ff6 ("Documentation/kbuild: Document platform dependency practises")
Link: https://lore.kernel.org/r/20220311093233.10012-1-zajec5@gmail.com
Signed-off-by: Greg Kroah-Hartman

serial: SERIAL_SUNPLUS should depend on ARCH_SUNPLUS

2022-03-18T12:16:05+00:00

Sunplus serial ports are only present on Sunplus SoCs.  Hence add a
dependency on ARCH_SUNPLUS, to prevent asking the user about this driver
when configuring a kernel without Sunplus SoC support.

Fixes: 9e8d5470325f25be ("serial: sunplus-uart: Add Sunplus SoC UART Driver")
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/59f46272ab5b16853acac4d585c3333cfd394223.1647352195.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman

Revert "tty: serial: meson: *"

2022-03-01T21:13:38+00:00

This reverts the following commits:

31979060cc07 tty: serial: meson: Fix the compile link error reported by kernel test robot
5427c352a993 tty: serial: meson: Added S4 SOC compatibility
19b2ba0baffc tty: serial: meson: The system stuck when you run the stty command on the console to change the baud rate
e5fc2b99840d tty: serial: meson: Make some bit of the REG5 register writable
44023b8e1f14 tty: serial: meson: Describes the calculation of the UART baud rate clock using a clock frame
6436dd8f9b25 tty: serial: meson: Use devm_ioremap_resource to get register mapped memory
841f913e770f tty: serial: meson: Move request the register region to probe

They seem to cause lots of problems with existing hardware platforms,
and caused build issues, so revert the whole series all at once.

Link: https://lore.kernel.org/r/849a95fd-ae81-9a3b-0c06-dd7826af9eb2@baylibre.com
Link: https://lore.kernel.org/all/20220225073922.3947-1-yu.tu@amlogic.com/
Reported-by: Marek Szyprowski 
Reported-by: Jerome Brunet 
Cc: Neil Armstrong 
Cc: Yu Tu 
Signed-off-by: Greg Kroah-Hartman

tty: serial: meson: Fix the compile link error reported by kernel test robot

2022-02-28T21:24:25+00:00

Describes the calculation of the UART baud rate clock using a clock
frame. Forgot to add in Kconfig kernel test Robot compilation error
due to COMMON_CLK dependency.

Fixes: 44023b8e1f14 ("tty: serial: meson: Describes the calculation of the UART baud rate clock using a clock frame")
Reported-by: kernel test robot 
Signed-off-by: Yu Tu 
Link: https://lore.kernel.org/r/20220228064910.11636-1-yu.tu@amlogic.com
Signed-off-by: Greg Kroah-Hartman

serial: sunplus-uart: Add Sunplus SoC UART Driver

2022-02-26T09:03:21+00:00

Add Sunplus SoC UART Driver.
SP7021 UART block contains 5 UARTs.
There are UART0~4 that supported in SP7021, the features list as below.
Support Full-duplex communication.
Support data packet length configurable.
Support stop bit number configurable.
Support force break condition.
Support baud rate configurable.
Support error detection and report.
Support RXD Noise Rejection Vote configurable.

UART0 pinout only support TX/RX two pins.
UART1 to UART4 pinout support TX/RX/CTS/RTS four pins.
Normally UART0 used for kernel console, also can be used for normal uart.
Command line set "console=ttySUP0,115200", SUP means Sunplus Uart Port.
UART driver probe will create path named "/dev/ttySUPx".

https://sunplus.atlassian.net/wiki/spaces/doc/pages/1873412290/13.+Universal+Asynchronous+Receiver+Transmitter+UART

Signed-off-by: Hammer Hsieh 
Link: https://lore.kernel.org/r/1645522563-17183-3-git-send-email-hammerh0314@gmail.com
Signed-off-by: Greg Kroah-Hartman

serial: mvebu-uart: implement UART clock driver for configuring UART base clock

2022-02-25T09:27:58+00:00

Implement a new device driver for controlling UART clocks on Marvell
Armada 3700 SoC. This device driver is loaded for devices which match
the compatible string "marvell,armada-3700-uart-clock".

There are more pitfalls related to UART clocks:
- both UARTs use same parent clock source (which can be xtal or one of
  the TBG clocks),
- if a TBG clock is used as the parent clock, there are two additional
  divisors that can both be configured to divide the rate by 1, 2, ... 6,
  but these divisors are again shared between the two UART controllers
  on the SOC,
- the configuration of the parent clock source and divisors is done in
  the address space of the first UART controller, UART1. Clocks can be
  gated separately for UART1 and UART2, but this setting also lives in
  the address space of UART1,
- Marvell's Functional Specification for Armada 3720 document has the
  clock gating bits swapped, so the one described to gate UART1 clock
  actually gates UART2 and vice versa,
- each UART has it's own "special divisor", and this uses the parent
  clock described above. These divisors are configure in each UART's
  address space separately.

Thus the driver for UART2 controller needs to have access to UART1
address space, since UART1 address space contains some bits exclusive
for UART2 and also some bits which are shared between UART1 and UART2.

Also, during boot, when early console is active on one of the UARTs,
and we want to switch parent clock from xtal (default) to TBG (to be
more flexible with baudrates), the driver changing UART clocks also
needs to be able to change the "special divisor", so that the baudrate
of earlycon is not changed when swtiching to normal console. Thus the
clock driver also needs to be able to access UART2 register space,
for UART2's "special divisor".

For these reasons, this new UART clock driver does not use
ioremap_resource(), but only ioremap() to prevent resource conflicts
between UART clock driver and UART driver.

We need to share only two 32-bit registers between the UART driver and
the UART clock driver:
- UART Clock Control
- UART 2 Baud Rate Divisor
Access to these two registers are protected by one spinlock to prevent
any conflicts. Access is required only during probing, when changing
baudrate or during suspend/resume.

Hardware can be configured to use one of following clocks as UART parent
clock: TBG-A-P, TBG-B-P, TBG-A-S, TBG-B-S, xtal. Not every clock is
usable for higher buadrates. Any subset can be specified in the
device-tree and the driver will choose the best one which also still
supports the mandatory baudrate of 9600 Bd. For smooth boot log output
it is needed to specify clock used by early console, otherwise garbage
would be printed on UART during probe of UART clock driver and
transitioning from early console to normal console.

We are implementing this to be able to configure TBG clock as UART
parent clock, which is required to be able to achieve higher baudrates
than 230400 Bd. We achieve this by referencing this new UART clock
device node in UART's device node. UART clock device driver
automatically chooses the best clock source for UART driver.

Until now, UART's device-tree node needed to reference one of the static
clocks (xtal or one of the TBGs) as parent clock in the `clocks`
phandle - the parent clock which was configured before booting the
kernel. If bootloader changed UART's parent clock, it needed to change
the `clocks` phandle in DTB correspondingly before booting.

From now on both the old mechanism (xtal or TBG referenced as parent
clock in `clocks` phandle) and the new one (UART clock referenced in the
`clocks` phandle) are supported, to provide full backward compatibility
with existing DTS files, full backward compatibility with existing boot
loaders, and to provide new features (runtime clock configuration to
allow higher baudrates than 230400 Bd). New features are available only
with new DTS files.

There was also a discussion about how the UART node and the
clock-controller node could be wrapped together in a new binding [1, 2].
As explained there, this is not possible if we want to keep backwards
compatibility with existing bootloaders, and thus we are doing this by
putting the UART clock-controller node inside the UART1 node.

[1] https://lore.kernel.org/linux-serial/20220120000651.in7s6nazif5qjkme@pali/
[2] https://lore.kernel.org/linux-serial/20220125204006.A6D09C340E0@smtp.kernel.org/

Reviewed-by: Marek Behún 
Reviewed-by: Stephen Boyd 
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
Link: https://lore.kernel.org/r/20220219152818.4319-4-kabel@kernel.org
Signed-off-by: Greg Kroah-Hartman

tty: serial: atmel: add earlycon support

2022-02-21T18:47:42+00:00

Add early console support which relies on the bootloader for the
initialization of the UART.
Please note, that the compatibles are taken from at91-usart MFD
driver.

Tested-by: Claudiu Beznea 
Reviewed-by: Claudiu Beznea 
Acked-by: Richard Genoud 
Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20220217094620.1148571-1-michael@walle.cc
Signed-off-by: Greg Kroah-Hartman

tty: serial: samsung: Enable console as module

2021-12-20T15:54:10+00:00

Enable serial driver to be built as a module. To do so, init the console
support on driver/module load instead of using console_initcall().

Inspired by commit 87a0b9f98ac5 ("tty: serial: meson: enable console as
module").

Signed-off-by: Sam Protsenko 
Reviewed-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20211204195757.8600-5-semen.protsenko@linaro.org
Signed-off-by: Greg Kroah-Hartman

serial: liteuart: relax compile-test dependencies

2021-11-25T17:25:49+00:00

The LITEX symbol is neither a build or runtime dependency for the
liteuart serial driver.

LITEX is selected by the "LiteX SoC Controller" driver, which does a
probe-time register-access sanity check and panics if the SoC has not
been configured correctly. That driver's Kconfig entry asserts that any
LiteX driver using the LiteX register accessors should depend on LITEX,
but currently only the serial driver complies.

Relax this LITEX "dependency" in order to make it easier to compile test
the driver.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Johan Hovold 
Link: https://lore.kernel.org/r/20211117100512.5058-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman