aboutsummaryrefslogtreecommitdiff
path: root/board/intel/bayleybay
diff options
context:
space:
mode:
authorMark Kettenis2022-02-21 22:17:37 +0100
committerTom Rini2022-03-08 08:42:43 -0500
commitc12f9d2e5496489c22aa265725cc71697d2de0cb (patch)
treedf4158f1d17ada7a941f41994554b0ed99e70775 /board/intel/bayleybay
parent45eb35c1979e928a2b086b090be86ac249114e62 (diff)
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>
Diffstat (limited to 'board/intel/bayleybay')
0 files changed, 0 insertions, 0 deletions