From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 855FDC433F5 for ; Mon, 21 Feb 2022 21:17:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8B1B583C34; Mon, 21 Feb 2022 22:17:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=openbsd.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=kpnmail.nl header.i=@kpnmail.nl header.b="K2BIJMJn"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F11B083A71; Mon, 21 Feb 2022 22:17:46 +0100 (CET) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 8FFAC83A71 for ; Mon, 21 Feb 2022 22:17:43 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=openbsd.org Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=kettenis@openbsd.org X-KPN-MessageId: b00c09bf-935b-11ec-9080-005056abbe64 Received: from smtp.kpnmail.nl (unknown [10.31.155.40]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id b00c09bf-935b-11ec-9080-005056abbe64; Mon, 21 Feb 2022 22:17:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kpnmail.nl; s=kpnmail01; h=mime-version:message-id:date:subject:to:from; bh=tOuyfi35A3QuPHsjf5RWFf5VKKGPcvtb7KhmjmK0Img=; b=K2BIJMJnWJWeB5riyGD7QterTFyMe3QdBpHWbkbyEIF5KFh77z+2CTwVO41bBt5C/zRvDfL21oe/M XMmFZgA4LVI/PCNB02OyLuxIL6mkpI9sf1wcNgyjCcDHYWF9YlLvbp5rZHk/DE42tKcv0XkLwNvAsS qZ/ead//hh0ua5IY= X-KPN-VerifiedSender: No X-CMASSUN: 33|ouTqfr62sj0oZ84YUbA9g313JknVsOgVKqVXFBtpXf7HdMJw6GTRY1rhBYFNVoK And/L96qygRePEB7Snmp5Eg== X-Originating-IP: 83.163.83.176 Received: from copland.sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) by smtp.xs4all.nl (Halon) with ESMTPSA id b49e4b68-935b-11ec-a9ea-005056ab7584; Mon, 21 Feb 2022 22:17:42 +0100 (CET) From: Mark Kettenis To: u-boot@lists.denx.de Cc: sjg@chromium.org, Mark Kettenis Subject: [PATCH v2] drivers: serial: Make sure we really return a serial device Date: Mon, 21 Feb 2022 22:17:37 +0100 Message-Id: <20220221211737.39653-1-kettenis@openbsd.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean 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 --- 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