U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@openbsd.org>
To: u-boot@lists.denx.de
Cc: sjg@chromium.org, Mark Kettenis <kettenis@openbsd.org>
Subject: [PATCH v2] drivers: serial: Make sure we really return a serial device
Date: Mon, 21 Feb 2022 22:17:37 +0100	[thread overview]
Message-ID: <20220221211737.39653-1-kettenis@openbsd.org> (raw)

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;
 	}
 
-- 
2.35.1


             reply	other threads:[~2022-02-21 21:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21 21:17 Mark Kettenis [this message]
2022-03-06  3:07 ` [PATCH v2] drivers: serial: Make sure we really return a serial device Simon Glass
2022-03-09 20:00 ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220221211737.39653-1-kettenis@openbsd.org \
    --to=kettenis@openbsd.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox