Message ID | 20231205073255.20562-1-tony@atomide.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp3265501vqy; Mon, 4 Dec 2023 23:34:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IFWwKg+lzI788uGjwF/EN6nw1wuNWiWb4D4Ya2HrcjOcsnEaPD8bFsTZ1l/wvsFSNNTdrNg X-Received: by 2002:a05:6871:d211:b0:1fb:75c:3fee with SMTP id pk17-20020a056871d21100b001fb075c3feemr7004066oac.78.1701761648078; Mon, 04 Dec 2023 23:34:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701761648; cv=none; d=google.com; s=arc-20160816; b=pynxP5AbIWSOH+kbD1csWkmN24Vsjh69YFaxI4tcQvHJdqvQPZDIkSTp4Q633K7lhu yo1T351UGtzZywxgVMklcfbVsvewiTuxphOohn9DMgNKq/EzR8FTurErTT/7dfWQ6yBt bHcEVMJYWEBWbgkKkyDLWdMD7clhsxzC7Bs9NYUXYRWJkW6Fh+gCGzgJb5QX0yJgRH9o 9bsYjGRaSTFcUcoK4S8DO5zLL+1aK9xY/OcZ59XuCYIovbFSsa9lKAt0Hnw1aN8EWRdd 8RqCOg1bp4INY8k3r+nqC6e6Y5wumtFxrq4SsD8di1IUURBZfvA9oFTR3aT4ErgKTWQe J8Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=yzyCE4K/ACUQx6Ez57RTWW9kcQULkeEaIYCt+UqTOXo=; fh=OQrZIrddo55Tm+afxTOsnGwFgD38y2NNd7tU+1OGSCE=; b=rPmjaLC8BTROB+9RgeHYdhxcud1asBX/LzCjj+KkjFDoDcUfAW0Ub0BTksWBniTMSz 9ch7Ef33IHqW7ilLbfuml3rrBJFYYWH7LIyQjPtQf0odU+L7cEwmbUNoEAARnpHnWkZf 9zwkBIt5Ul+Y0kgaH0OydJC+0auzor6Jv7ECZ0U9GTHlwHZzQBIoybhDUUBnolzRM7e0 R7y7Gc8tQKXaPfA5nSJVEDRG5CjrpY7Cho0c1pk47rnk94DyaBpvtUhprb6ln18Pp8EN OHVBLlbZ4zTZjEYUFKH3X1Akf3wpDafAIvik45I8vYB6DZbo4AITPECURXY0SpXColHV Vayg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@atomide.com header.s=25mailst header.b=mfq7qOTQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id bx25-20020a056a02051900b005c693ea6618si2718819pgb.523.2023.12.04.23.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 23:34:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=fail header.i=@atomide.com header.s=25mailst header.b=mfq7qOTQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id D9DA280AFEA6; Mon, 4 Dec 2023 23:34:05 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344331AbjLEHdn (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Tue, 5 Dec 2023 02:33:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231705AbjLEHdl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 5 Dec 2023 02:33:41 -0500 Received: from mail5.25mail.st (mail5.25mail.st [74.50.62.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 747A2CB; Mon, 4 Dec 2023 23:33:47 -0800 (PST) Received: from localhost (91-158-86-216.elisa-laajakaista.fi [91.158.86.216]) by mail5.25mail.st (Postfix) with ESMTPSA id 180E860354; Tue, 5 Dec 2023 07:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=atomide.com; s=25mailst; t=1701761626; bh=7h5wlzQdpRnMNvGKsqPPaRZvd85tYn+u1pMnFtiPN10=; h=From:To:Cc:Subject:Date:From; b=mfq7qOTQojPAcWlc+l43nDG3ElnzK+UoO/XbCuDC8Lsfc0CvFKnZjXGhhtf6W3nmQ 1DkHSRTW9WM+dZ5Ccn1a0+W/dVz6iKgy0zcCag6WAygvE6/LaOkSYKh+SOWubbNmmp ihes/iJyRU+7+gc4RnL6KWPyLu6PjGkt9cNhvcLY+k3yrbVD0VN0ZIo5AwA/gCbo5U fPbzECjGWgolo38YGoPzcUh1Nkn0j/1jS7IfOgGjo8M31+Cn+p+yqpJxMTaymXhdGJ g7CsRZmJv6PUEDEygd0nDG1dMh15RvZ59OO/D0Hw/UAtF0EUI0k/hhjY7ABvhbBU4H 0TYeBUQY0GC4w== From: Tony Lindgren <tony@atomide.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org>, Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>, John Ogness <john.ogness@linutronix.de>, Sergey Senozhatsky <senozhatsky@chromium.org> Cc: "David S . Miller" <davem@davemloft.net>, Andy Shevchenko <andriy.shevchenko@intel.com>, Dhruva Gole <d-gole@ti.com>, =?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>, Johan Hovold <johan@kernel.org>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Vignesh Raghavendra <vigneshr@ti.com>, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Subject: [PATCH v4 0/4] Add support for DEVNAME:0.0 style hardware based addressing Date: Tue, 5 Dec 2023 09:32:32 +0200 Message-ID: <20231205073255.20562-1-tony@atomide.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 04 Dec 2023 23:34:06 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784426421740447840 X-GMAIL-MSGID: 1784426421740447840 |
Series |
Add support for DEVNAME:0.0 style hardware based addressing
|
|
Message
Tony Lindgren
Dec. 5, 2023, 7:32 a.m. UTC
Hi all, With the recent serial core changes, we can now add DEVNAME:0.0 style addressing for the serial ports. When using DEVNAME:0.0 naming, we don't need to care which ttyS instance number is allocated depending on HSUART settings or if the devicetree has added aliases for all the ports. We also prepare the serial core to handle the ttyS related quirks done in console_setup() to prepare things for eventually dropping the parsing from console_setup(). This can only happen after further changes to register_console(). Regards, Tony Changes since v3: - Fix handling of brl_options by saving them too in console_opt_save() - Drop changes to remove console_setup() parsing, further changes to register_console() are still needed before can leave out the early parsing - Added a patch for serial8250_isa_init_preferred_console(), otherwise the console gets initialized later for x86 when the console_setup() parsing is dropped as pointed out by Petr - Initialize __free() variables to NULL as noted by Dan - Return handled in console_setup() if saving console options fails - Simplify serial_base_add_preferred_console() and add a helper for serial_base_add_one_prefcon() as suggested by Andy - Header include changes to kernel/printk/conopt.c as suggested by Andy Changes since v2: - Console name got constified and already applied as suggested by Ilpo and Andy - Add printk/conopt.c to save console command line options - Add a patch to drop old console_setup() character device name parsing - Use cleanup.h to simplify freeing as suggested by Andy - Use types.h instead of kernel.h as suggested by Andy - Use strcspn() as suggested by Andy - Various coding improvments suggested by Andy Changes since v1: - Constify printk add_preferred_console() as suggested by Jiri - Use proper kernel command line helpers for parsing console as suggested by Jiri - Update description for HSUART based on Andy's comments - Standardize on DEVNAME:0.0 style naming as suggested by Andy - Added missing put_device() calls paired with device_find_child() Tony Lindgren (4): printk: Save console options for add_preferred_console_match() serial: core: Add support for DEVNAME:0.0 style naming for kernel console serial: core: Handle serial console options serial: 8250: Add preferred console in serial8250_isa_init_ports() drivers/tty/serial/8250/8250_core.c | 32 +++++++ drivers/tty/serial/serial_base.h | 14 +++ drivers/tty/serial/serial_base_bus.c | 115 ++++++++++++++++++++++++ drivers/tty/serial/serial_core.c | 4 + include/linux/printk.h | 3 + kernel/printk/Makefile | 2 +- kernel/printk/conopt.c | 128 +++++++++++++++++++++++++++ kernel/printk/console_cmdline.h | 6 ++ kernel/printk/printk.c | 14 ++- 9 files changed, 314 insertions(+), 4 deletions(-) create mode 100644 kernel/printk/conopt.c
Comments
* Tony Lindgren <tony@atomide.com> [700101 02:00]: > We also prepare the serial core to handle the ttyS related quirks done > in console_setup() to prepare things for eventually dropping the parsing > from console_setup(). This can only happen after further changes to > register_console(). Petr FYI, so for dropping the console_setup() parsing, below is a hack patch to see what goes wrong in register_console() if you have some ideas on how to handle this. We end up with the console device backed up seria8250 instead of ttyS0, and earlycon won't get properly disabled. And of course other consoles beyond ttyS need to be also considered. Regards, Tony 8< ---------------------- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2438,9 +2438,7 @@ __setup("console_msg_format=", console_msg_format_setup); */ static int __init console_setup(char *str) { - char buf[sizeof(console_cmdline[0].name) + 4]; /* 4 for "ttyS" */ - char *s, *options, *brl_options = NULL; - int idx; + char *brl_options = NULL; /* * console="" or console=null have been suggested as a way to @@ -2459,32 +2457,9 @@ static int __init console_setup(char *str) if (console_opt_save(str, brl_options)) return 1; - /* - * Decode str into name, index, options. - */ - if (str[0] >= '0' && str[0] <= '9') { - strcpy(buf, "ttyS"); - strncpy(buf + 4, str, sizeof(buf) - 5); - } else { - strncpy(buf, str, sizeof(buf) - 1); - } - buf[sizeof(buf) - 1] = 0; - options = strchr(str, ','); - if (options) - *(options++) = 0; -#ifdef __sparc__ - if (!strcmp(str, "ttya")) - strcpy(buf, "ttyS0"); - if (!strcmp(str, "ttyb")) - strcpy(buf, "ttyS1"); -#endif - for (s = buf; *s; s++) - if (isdigit(*s) || *s == ',') - break; - idx = simple_strtoul(s, NULL, 10); - *s = 0; + /* Indicate register_console() a console was specified */ + console_set_on_cmdline = 1; - __add_preferred_console(buf, idx, options, brl_options, true); return 1; } __setup("console=", console_setup); @@ -3476,7 +3451,7 @@ void register_console(struct console *newcon) * Note that a console with tty binding will have CON_CONSDEV * flag set and will be first in the list. */ - if (preferred_console < 0) { + if (preferred_console < 0 && !console_set_on_cmdline) { if (hlist_empty(&console_list) || !console_first()->device || console_first()->flags & CON_BOOT) { try_enable_default_console(newcon);
* Tony Lindgren <tony@atomide.com> [700101 02:00]: > * Tony Lindgren <tony@atomide.com> [700101 02:00]: > > We also prepare the serial core to handle the ttyS related quirks done > > in console_setup() to prepare things for eventually dropping the parsing > > from console_setup(). This can only happen after further changes to > > register_console(). > > Petr FYI, so for dropping the console_setup() parsing, below is a hack > patch to see what goes wrong in register_console() if you have some ideas > on how to handle this. > > We end up with the console device backed up seria8250 instead of ttyS0, > and earlycon won't get properly disabled. And of course other consoles > beyond ttyS need to be also considered. Hmm so the following extra patch seems to fix the issues based on light testing. But is it safe to assume that if CON_PRINTBUFFER is set we can disable the bootconsole? I also noticed that the bootconsole not getting disabled issue is there also for console=DEVNAME:0.0 usage even before we start dropping handling in console_setup(). Regards, Tony 8< ---------------------- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -3549,7 +3549,8 @@ void register_console(struct console *newcon) */ con_printk(KERN_INFO, newcon, "enabled\n"); if (bootcon_registered && - ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV) && + !(newcon->flags & CON_BOOT) && + (newcon->flags & (CON_CONSDEV | CON_PRINTBUFFER)) && !keep_bootcon) { struct hlist_node *tmp;
* Tony Lindgren <tony@atomide.com> [231208 10:29]: > * Tony Lindgren <tony@atomide.com> [700101 02:00]: > > * Tony Lindgren <tony@atomide.com> [700101 02:00]: > > > We also prepare the serial core to handle the ttyS related quirks done > > > in console_setup() to prepare things for eventually dropping the parsing > > > from console_setup(). This can only happen after further changes to > > > register_console(). > > > > Petr FYI, so for dropping the console_setup() parsing, below is a hack > > patch to see what goes wrong in register_console() if you have some ideas > > on how to handle this. > > > > We end up with the console device backed up seria8250 instead of ttyS0, > > and earlycon won't get properly disabled. And of course other consoles > > beyond ttyS need to be also considered. > > Hmm so the following extra patch seems to fix the issues based on light > testing. But is it safe to assume that if CON_PRINTBUFFER is set we can > disable the bootconsole? OK so no need for the CON_PRINTBUFFER change, it's wrong. I found a few bugs causing this issue and a lot of other confusion while testing: - In console_setup(), a DEVNAME:0.0 style console can get added with the IO address turned into a ttyS console with some crazy index :) So we need to bail out early on consoles with ':' in the name. - The brl_opts can be empty or NULL, but we need to pass NULL to __add_preferred_console() to get CON_CONSDEV flag set for DEVNAME:0.0 console. Otherwise the preferred_console won't get set and the boot console won't get disabled. - The console_set_on_cmdline flag needs to be set if console_setup() does not call __add_preferred_console() for DEVNAME:0.0 style console as otherwise try_enable_default_console() may get called before the console handling driver has added the preferred console. I think with these the remaining issues are sorted out :) I'll post a v5 set with as RFC as it's getting close to the merge window. Regards, Tony