Received: by 2002:ab2:b82:0:b0:1f3:401:3cfb with SMTP id 2csp254167lqh; Thu, 28 Mar 2024 00:22:39 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVk5Gwcf4er/JbH+nXApMheW0DLwNmw7FSnKbOmxUmV6F7WxbjB3O8qjihaD0N5L7QJp57WLqt+sMZfApoRBTUZvelCxPBo0/yBhlCeqQ== X-Google-Smtp-Source: AGHT+IFgHfYCtdMubpUYVyBcGfHUvWRi/4BpWfGWw79MWVldMGETdJMUDzGkbhUTip0GKQ0+gB40 X-Received: by 2002:a17:906:c7d8:b0:a4e:757:989a with SMTP id dc24-20020a170906c7d800b00a4e0757989amr1076487ejb.8.1711610559138; Thu, 28 Mar 2024 00:22:39 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711610559; cv=pass; d=google.com; s=arc-20160816; b=gaUvF30Pq4Ye80J5JfyJ5L6kAoO1yic7N2Cr1ST0YSdZawnHdu7HUxz6pymzD0HWLe EIWRagW+pNxl89GgAtzOuiKUyswwiOok8MSBFY5GnE8ArvBoTURe2DzQZ6dOpO6RUwMv dBgSxHRfWVA7i/myDRB0GHHljF1v/JPrn9GAdqemppAk55ewSqCLYnYJ2YNvWSsgpj9N XIGRo5lS6hD/cCDG+b4kbM4i0BO+h9lcBhrBeffDDPer3oSkUb/nSLWSdbc4ap7pOpMi byhK+VKOUpLUf5j5cKKUSIoWxrbfBzHRw1oJvdlrwsT5hQtHp2NiiOBrSlqYeOSpmvgD JwMw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=QVE+6si3vNTQ1xSXZojsIoAh5uVOIRNUTk23SHzxSUg=; fh=Asdtem2yNtlzyWJMLRup1+iqOZW2jXdrt+GQUFGoh3M=; b=bQ1zrovuVjAhXGmJbIc1yFUA41BF8Uhftdl6+4qY6tPrxrpRISDG1Qm9B9yiG7ikOC OcUjKUZSasnK50mas1FOKI8bRRzrm7N/3GxgMQcTGxh1Hd/0lONLiStIfa9rznTBxRZj Z3S1o0yQmp+KqZxI+WyMcXqyb/65tj8yrltsJ13qDuQOSsg/DS3Km1u6JZiDnrFyU5vd EKhNICDAAMo0NiK8YX5KsPXFa8c42kjkXfY7RzT/oTAF4E1xgdnAXVITCjrailJ6fJLj mPcrn6KcYo/j1EKuPwdg/coVS1qsBWFBTWWYQSthG7nRXESICD3NoCY3/VSNdav3J3WI 8Adg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=gyEAHABQ; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-122495-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-122495-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id s4-20020a170906a18400b00a46caa13e58si414936ejy.418.2024.03.28.00.22.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Mar 2024 00:22:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-122495-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=gyEAHABQ; arc=pass (i=1 dkim=pass dkdomain=linuxfoundation.org); spf=pass (google.com: domain of linux-kernel+bounces-122495-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-122495-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id B3CE51F24D29 for ; Thu, 28 Mar 2024 07:22:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 56A1950A63; Thu, 28 Mar 2024 07:22:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="gyEAHABQ" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25606849C; Thu, 28 Mar 2024 07:22:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711610550; cv=none; b=Esm4oQ6bxDjQAo/AwghyDz7QpVAFPxw15AtDAwCxKxd12MsboUgCUcW8BOfgyIFDDMlG56sjTaYuLyZ5mRPjpDf2Odrrjb3pm3scg9eVdJpqGtcCle3gu0wdk7mI1Vr7J+k4gRkeYS32ebtT+LJMudTPmYkJ5mJe0EgC44MS5ug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711610550; c=relaxed/simple; bh=hiuS5t2lQWNJFOtvJipQHkQ+4rNrV1yVGvL5Ol0zhKw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fpak4TIKK3Bo5YFZYom7TjepyAnt0dCeEB3CbgkytOWkbgpjukuWfSwASxGb2AR+SalpPWRMAy/c9Rf1AvMIQIWoW95kVBkRnh142LUEHSpfgcYp1poQSB8AIEObeSIUNhEbSL7vVk4LpXGiDge/qnBqWmvR5P5OR7Tz3tDB43E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=gyEAHABQ; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08251C433C7; Thu, 28 Mar 2024 07:22:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1711610549; bh=hiuS5t2lQWNJFOtvJipQHkQ+4rNrV1yVGvL5Ol0zhKw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gyEAHABQAOXEaDE2eUHd+AvzyH/aWOHeeO+fh5qBiDREXjVngZB5Adj0TtNccYEM7 KHjq51WVF199wxpVIpQMwmGmLfW3bNGFRXx05M5FIeYdh/7qkyxd7dBQk4Kg3YKTZA hDp/xaz5XlV1gcGT7c3uUo/pN46cC+jlohAHmAxc= Date: Thu, 28 Mar 2024 08:22:26 +0100 From: Greg Kroah-Hartman To: Dhruva Gole Cc: Tony Lindgren , Jiri Slaby , Jonathan Corbet , Petr Mladek , Steven Rostedt , John Ogness , Sergey Senozhatsky , "David S . Miller" , Andy Shevchenko , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , Johan Hovold , Sebastian Andrzej Siewior , Vignesh Raghavendra , linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, Sebastian Reichel , linux-doc@vger.kernel.org Subject: Re: [PATCH v7 4/7] serial: core: Add support for DEVNAME:0.0 style naming for kernel console Message-ID: <2024032859-subscript-marshy-7508@gregkh> References: <20240327110021.59793-1-tony@atomide.com> <20240327110021.59793-5-tony@atomide.com> <20240328063152.bjkdtdsu42cqbgf3@dhruva> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240328063152.bjkdtdsu42cqbgf3@dhruva> On Thu, Mar 28, 2024 at 12:01:52PM +0530, Dhruva Gole wrote: > Hi, > > On Mar 27, 2024 at 12:59:38 +0200, Tony Lindgren wrote: > > We can now add hardware based addressing for serial ports. Starting with > > commit 84a9582fd203 ("serial: core: Start managing serial controllers to > > enable runtime PM"), and all the related fixes to this commit, the serial > > core now knows to which serial port controller the ports are connected. > > > > The serial ports can be addressed with DEVNAME:0.0 style naming. The names > > are something like 00:04:0.0 for a serial port on qemu, and something like > > 2800000.serial:0.0 on platform device using systems like ARM64 for example. > > > > The DEVNAME is the unique serial port hardware controller device name, AKA > > the name for port->dev. The 0.0 are the serial core controller id and port > > id. > > > > Typically 0.0 are used for each controller and port instance unless the > > serial port hardware controller has multiple controllers or ports. > > > > Using DEVNAME:0.0 style naming actually solves two long term issues for > > addressing the serial ports: > > > > 1. According to Andy Shevchenko, using DEVNAME:0.0 style naming fixes an > > issue where depending on the BIOS settings, the kernel serial port ttyS > > instance number may change if HSUART is enabled > > > > 2. Device tree using architectures no longer necessarily need to specify > > aliases to find a specific serial port, and we can just allocate the > > This is GOOD! > > > ttyS instance numbers dynamically in whatever probe order > > > > To do this, let's match the hardware addressing style console name to > > the character device name used, and add a preferred console using the > > character device name. > > > > Note that when using console=DEVNAME:0.0 style kernel command line, the > > 8250 serial console gets enabled later compared to using console=ttyS > > naming for ISA ports. This is because the serial port DEVNAME to character > > device mapping is not known until the serial driver probe time. If used > > together with earlycon, this issue is avoided. > > > > Signed-off-by: Tony Lindgren > > --- > > drivers/tty/serial/serial_base.h | 16 +++++++ > > drivers/tty/serial/serial_base_bus.c | 66 ++++++++++++++++++++++++++++ > > drivers/tty/serial/serial_core.c | 4 ++ > > 3 files changed, 86 insertions(+) > > > > diff --git a/drivers/tty/serial/serial_base.h b/drivers/tty/serial/serial_base.h > > --- a/drivers/tty/serial/serial_base.h > > +++ b/drivers/tty/serial/serial_base.h > > @@ -45,3 +45,19 @@ void serial_ctrl_unregister_port(struct uart_driver *drv, struct uart_port *port > > > > int serial_core_register_port(struct uart_driver *drv, struct uart_port *port); > > void serial_core_unregister_port(struct uart_driver *drv, struct uart_port *port); > > + > > +#ifdef CONFIG_SERIAL_CORE_CONSOLE > > + > > +int serial_base_add_preferred_console(struct uart_driver *drv, > > + struct uart_port *port); > > + > > +#else > > + > > +static inline > > +int serial_base_add_preferred_console(struct uart_driver *drv, > > + struct uart_port *port) > > +{ > > + return 0; > > +} > > + > > +#endif > > diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c > > --- a/drivers/tty/serial/serial_base_bus.c > > +++ b/drivers/tty/serial/serial_base_bus.c > > @@ -8,6 +8,7 @@ > > * The serial core bus manages the serial core controller instances. > > */ > > > > +#include > > #include > > #include > > #include > > @@ -204,6 +205,71 @@ void serial_base_port_device_remove(struct serial_port_device *port_dev) > > put_device(&port_dev->dev); > > } > > > > +#ifdef CONFIG_SERIAL_CORE_CONSOLE > > + > > +static int serial_base_add_one_prefcon(const char *match, const char *dev_name, > > + int port_id) > > +{ > > + int ret; > > + > > + ret = add_preferred_console_match(match, dev_name, port_id); > > + if (ret == -ENOENT) > > + return 0; > > + > > + return ret; > > Can we do this instead? > return (ret == -ENOENT ? 0 : ret); No, please no. Just spell it out, like was done here, dealing with ? : is a pain to read and follow and the generated code should be identical. Only use ? : in places where it's the only way to do it (i.e. as function parameters or in printk-like lines.) Write for people first, compilers second. thanks, greg k-h