There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.

Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.

Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.

Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Changing baudrate is a sensitive operation. To ensure that U-Boot messages
printed before changing baudrate are not lost, call new U-Boot console
flush() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Like in all other console functions, implement also serial_flush() function
as a fallback int console flush() function.

Flush support is available only when config option CONSOLE_FLUSH_SUPPORT is
enabled. So when it is disabled then provides just empty static inline
function serial_flush().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

UART drivers have putc/puts functions which just put characters into HW
transmit queue and do not wait until all data are transmitted.

Implement flush callback via serial driver's pending(false) callback which
waits until HW transmit all characters from the queue.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Globally replace all occurances of WATCHDOG_RESET() with schedule(),
which handles the HW_WATCHDOG functionality and the cyclic
infrastructure.

Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]

A string like "test\n" would be broken up into the following sequence of
prints by _serial_puts:

	puts("test\n")
	putc('\r')

Although functionally this is the same as \r\n, it is not the standard
sequence and caused tests to fail. Fix this by excluding the '\n' from
the initial print. The above string will now be broken up like

	puts("test")
	puts("\r\n")

Since we may now need to call ops->puts twice (with the associated retry
logic), break that part of the function off into a helper.

Fixes: 7a76347189 ("serial: dm: Add support for puts")
Signed-off-by: Sean Anderson <sean.anderson@seco.com>

Some serial drivers can be vastly more efficient when printing multiple
characters at once. Non-DM serial has had a puts option for these sorts
of drivers; implement it for DM serial as well.

Because we have to add carriage returns, we can't just pass the whole
string directly to the serial driver. Instead, we print up to the
newline, then print a carriage return, and then continue on. This is
less efficient, but it is better than printing each character
individually. It also avoids having to allocate memory just to add a few
characters.

Drivers may perform short writes (such as filling a FIFO) and return the
number of characters written in len. We loop over them in the same way
that _serial_putc loops over putc.

This results in around sizeof(void *) growth for all boards with
DM_SERIAL. The full implementation takes around 140 bytes.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The stdout-path property in the device tree does not necessarily
point at a serial device. On machines such as the Apple M1 laptops
where the serial port isn't easy to access and users expect to see
console output on the integrated display stdout-path may point at
the device tree node for the framebuffer for example.

If stdout-path does not point at a node for a serial device, the
serial_check_stdout() will not find a bound device and will drop
down into code that attempts to use lists_bind_fdt() to bind a
device anyway. However, that fallback code does not check that
the uclass of the device is UCLASS_SERIAL. So if stdout-path points
at the framebuffer instead of the serial device it will return a
UCLASS_VIDEO device. Since the code that calls this function
expects the returned device to be a UCLASS_SERIAL device, U-Boot
will crash as soon as it attempts to send output to the console.

Add a check here to verify that the uclass of the bound device
really is UCLASS_SERIAL. If it isn't, serial_check_stdout() will
return an error and serial_find_console_or_panic() will use the
serial device with sequence number 0 as the console and all is fine.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

if CONFIG_DM_STDIO is defined but SERIAL_PRESENT not,
gcc drops warnings for serial_stub_* functions
that they are defined but not used.

Fix it.

Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

This old macro is not needed anymore since we can use IS_ENABLED() now.
Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>