drivers: serial: Make sure we really return a serial device
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>
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 362cedd..f30f352 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -66,7 +66,8 @@
*/
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;
}