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 ---

ChangeLog:

v2: - Expand commit message

drivers/serial/serial-uclass.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index 362cedd955..f30f352bd7 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -66,7 +66,8 @@ static int serial_check_stdout(const void *blob, struct udevice **devp) */ if (node > 0 && !lists_bind_fdt(gd->dm_root, offset_to_ofnode(node), devp, NULL, false)) { - if (!device_probe(*devp)) + if (device_get_uclass_id(*devp) == UCLASS_SERIAL && + !device_probe(*devp)) return 0; }