kernel/linux.git/drivers/tty/serial/earlycon.c, branch v6.12.81

earlycon: Let users set the clock frequency

2023-01-19T13:56:44+00:00

Some platforms, namely AMD Picasso, use non standard uart clocks (48M), witch makes it impossible to use with earlycon. Let the user select its own frequency. Signed-off-by: Ricardo Ribalda Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20221123-serial-clk-v3-1-49c516980ae0@chromium.org Signed-off-by: Greg Kroah-Hartman

tty: serial: earlycon: use console_is_registered()

2022-12-02T10:25:01+00:00

It is not reliable to check for CON_ENABLED in order to identify if a console is registered. Use console_is_registered() instead. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20221116162152.193147-27-john.ogness@linutronix.de

tty: move from strlcpy with unused retval to strscpy

2022-08-30T12:21:59+00:00

Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Reviewed-by: Jiri Slaby Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20220818210113.7469-1-wsa+renesas@sang-engineering.com Signed-off-by: Greg Kroah-Hartman

earlycon: prevent multiple register_console()

2022-06-30T15:10:11+00:00

If the earlycon parameter is given twice, the kernel will spit out a WARN() in register_console() because it was already registered. The non-dt variant setup_earlycon() already handles that gracefully. The dt variant of_setup_earlycon() doesn't. Add the check there and add the -EALREADY handling in early_init_dt_scan_chosen_stdout(). FWIW, this doesn't happen if CONFIG_ACPI_SPCR_TABLE is set. In that case the registration is delayed until after earlycon parameter(s) are parsed. Reviewed-by: Rob Herring Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20220628120705.200617-1-michael@walle.cc Signed-off-by: Greg Kroah-Hartman

earlycon: simplify earlycon-table implementation

2020-12-04T14:49:48+00:00

Instead of using the array-of-pointers trick to avoid having gcc mess up the earlycon array stride, specify type alignment when declaring entries to prevent gcc from increasing alignment. This is essentially an alternative (one-line) fix to the problem addressed by commit dd709e72cb93 ("earlycon: Use a pointer table to fix __earlycon_table stride"). gcc can increase the alignment of larger objects with static extent as an optimisation, but this can be suppressed by using the aligned attribute when declaring variables. Note that we have been relying on this behaviour for kernel parameters for 16 years and it indeed hasn't changed since the introduction of the aligned attribute in gcc-3.1. Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20201123102319.8090-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

tty: serial: print earlycon info after match->setup

2020-09-16T11:16:20+00:00

8250 devices may modify iotype in their own earlycon setup. For example: 8250_mtk and 8250_uniphier force iotype to be MMIO32. Print earlycon info after match->setup to reflect actual earlycon info. Signed-off-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20200915054825.3289105-1-hsinyi@chromium.org Signed-off-by: Greg Kroah-Hartman

serial: earlycon: prefer EARLYCON_DECLARE() variant

2020-03-07T08:52:01+00:00

If a driver exposes early consoles with EARLYCON_DECLARE() and OF_EARLYCON_DECLARE(), pefer the non-OF variant if the user specifies it by earlycon=, The rationale behind this is that some drivers register multiple setup functions under the same driver name. Eg. OF_EARLYCON_DECLARE(lpuart, "fsl,vf610-lpuart", lpuart_early_console_setup); OF_EARLYCON_DECLARE(lpuart32, "fsl,ls1021a-lpuart", lpuart32_early_console_setup); OF_EARLYCON_DECLARE(lpuart32, "fsl,imx7ulp-lpuart", lpuart32_imx_early_console_setup); EARLYCON_DECLARE(lpuart, lpuart_early_console_setup); EARLYCON_DECLARE(lpuart32, lpuart32_early_console_setup); It depends on the order of the entries which console_setup() actually gets called. To make things worse, I guess it also depends on the compiler how these are ordered. Thus always prefer the EARLYCON_DECLARE() ones. Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20200220174607.24285-1-michael@walle.cc Signed-off-by: Greg Kroah-Hartman

earlycon: Remove hardcoded port->uartclk initialization in of_setup_earlycon

2018-05-14T11:41:05+00:00

There is no reason to initialize uartclk to BASE_BAUD * 16 for DT based systems. Signed-off-by: Michal Simek Tested-by: Matt Redfearn Signed-off-by: Greg Kroah-Hartman

Merge 4.17-rc3 into tty-next

2018-04-30T12:14:55+00:00

We want the tty and serial driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman

earlycon: Initialize port->uartclk based on clock-frequency property

2018-04-23T08:14:57+00:00

On DT based platforms when current-speed property is present baudrate is setup. Also port->uartclk is initialized to bogus BASE_BAUD * 16 value. Drivers like uartps/ns16550 contain logic when baudrate and uartclk is used for baudrate calculation. The patch is reading optional clock-frequency property to replace bogus BASE_BAUD * 16 calculation to have proper baudrate calculation. Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman