From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D84E718787A for ; Wed, 10 Dec 2025 14:38:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765377509; cv=none; b=XREMqe7dfv/f1oXRnYiYQYN2SY1lpnBnPvHuAKPZDRlntdWmaUwD6BkIGV/4Hc8afYu55ZZGrfQ6Scio/zEjB7G7W9z4h7ojIgCI1OnnlAktCacNeiQTobeIWiPRUKEo/RJ1vaRN0hLLrTpYvyrFdZcrY3+om9AJI6S42UV5Erg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765377509; c=relaxed/simple; bh=B60da04myI9AT3WbA+wJ83c44fpdDWZ8ZyNrh1xPCA8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PrrKIbKw7ClTtgzFSl9VlfPZdpBPhEuah0ApvOcHoUPAspQl/AlFkNGwCGPhoq7VWWypU2pIsYg0BlZCY8eqb/GX+gIRwVnWZOhHAeCJ2kBgSGh9FvyhRdtwV83YQD1SZOsFOzcv6I2BGNacdAujuadkzAQa+LFcCkqmUZXeZeg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=XLOSmsoG; arc=none smtp.client-ip=209.85.221.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="XLOSmsoG" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-42e2e52cc04so2501767f8f.0 for ; Wed, 10 Dec 2025 06:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1765377505; x=1765982305; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WcCpYn34WXHq6hZdi+Z+3OJxHdxRDyksK4sFBB5Sg5Q=; b=XLOSmsoGWdB7RzhxDV4xxTCWLDJOtQWkW90vBBuVZR7Pnw1CnwJ4ZjrbQ0CV2L97qQ 14MgGM8OCr0ZSDkIRAMxiBDj1glvqIRJthHGO4SKrZTDy+qt2fgCY5sBT1+oYZHMr1Th G/vJs0u0uxsgASvTy3s+uRqmrrtm2M1vgyZQT14CW18fPjY+rqo70H9OEpGYTyfY4noE xiq6wGC+gVyZ0wgX9i3M+d92uy4M8isSCNUgpm9/IrLRw+VghB9se06QnXH0bPE9Njhj fvAbtY6vEN3dcRjIvxN1PPAYxMK1lBppBgkuPrRhvdAw4/4/SZeYbK4RGbRPFeoqQS83 XJhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765377505; x=1765982305; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WcCpYn34WXHq6hZdi+Z+3OJxHdxRDyksK4sFBB5Sg5Q=; b=ks5wB2EzYr8rTGEb2553mWk99xvG+mswQ6TBIdEmbVN92/Y7WHiKbRSzfj/JF4VgPx Tre5bqyOcaHJ05yFBeL3DDu4cuWXYbZAa9eJZ2MyJKCU7t+nIHL7IXQ7/gzW/kYvIvKs 43L0luSPTS97AS+lrUjBEEAVU74siq1j/NdmExGoyydQAmCGInAlG54TOWaPD5pHpJWw WWgP5/xb1Cegv9ER1eVdlxuqN+kfQWB6SX6c6RptzpQBBer7B2ddi1i5wVFBwMZYnzpY nVVhIUjdTHofuhr8eNq7brbujbAXt9Ln543WmzuhH03yTzShiJl1+14gpUd6TsCx/s9k qs3w== X-Gm-Message-State: AOJu0Yz6tGLLQtNmxzvBYtDj8rdSQrx35eQF82skp39AjEwzw8Z/5Iui XHpR0QrQ19Igb+CQT9WMeQ5DTVJdkWMp0pfVN10pV5qcVtv4WNn6VCZZbE7SvLrmAVM= X-Gm-Gg: AY/fxX4PTrszfs3TnmEbRxYgUEO2lXtQqw8ZLyValOxc71G2OkceG3aYk+iyXbWWrMh 49T82pK47ulmVGac+EWc5vUfIJAZPZ27JnwLNmWXAFC9RRRkvRdWysd5a+KyYGKXiByofBwPJJb UahddUo72bgTNZ2aJroL87V0RQ9xDojK0AK4IblIOLIllYGUq0gQ6643kbuWtZ6vRL94Vw64qle 6mx2ie/wRxB0zxHl9l87Yp96mL13N7AHHD7us7VTqveeR58g00Aw8uedepn3N8jPWXV/D1WuEAq yR48DzXQ79WdQ8Nskl/iD3J33Kn7U+sxqsnvPOlUauIBt/ppYjsjSY5pnh9yWOpuTCHvFVy/TU8 HmCnKVeH5ogAXwc/rU6GvlwlhMRzpDbT3ONO+OZ0k5LCFTk7AfHh2+D/JEnkL+pfzW5rYP/uZ8n BKpsHBlqHofVCDSg== X-Google-Smtp-Source: AGHT+IGhgSuYN5RF/J/LxieCXIL6igfAIJWP1dTDJuTgv78bNghGAtuhf69kpqyA0v6eAkaVBle+ag== X-Received: by 2002:a05:6000:4301:b0:42b:39fb:e87f with SMTP id ffacd0b85a97d-42fa3b06d64mr2871890f8f.49.1765377505029; Wed, 10 Dec 2025 06:38:25 -0800 (PST) Received: from pathway ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7d352a52sm38952047f8f.38.2025.12.10.06.38.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Dec 2025 06:38:24 -0800 (PST) Date: Wed, 10 Dec 2025 15:38:23 +0100 From: Petr Mladek To: Chris Down Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sergey Senozhatsky , Steven Rostedt , John Ogness , Geert Uytterhoeven , Tony Lindgren , kernel-team@fb.com Subject: Re: [PATCH v8 03/21] printk: Prioritise user-specified configuration over SPCR/DT Message-ID: References: <4661330ae686768ddbb249f54d6df5f4806cf40d.1764272407.git.chris@chrisdown.name> 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: <4661330ae686768ddbb249f54d6df5f4806cf40d.1764272407.git.chris@chrisdown.name> On Fri 2025-11-28 03:43:21, Chris Down wrote: > ACPI firmware routinely calls add_preferred_console() via > acpi_parse_spcr() before we ever look at the kernel command line. After > that first registration we short-circuit on every duplicate name/index > match, so the subsequent console=ttyS0,... parameter never refreshes the > UART options that the firmware supplied. > > Historically that just meant you couldn't tweak baud/flow control for a > firmware-provided serial console unless you picked a different device > name, but the per-console loglevel plumbing in this series relies on > those later console= entries being able to update the stored option > string. Without that, console=ttyS0,loglevel:5 simply never takes effect > on machines that get their console from SPCR/DT. > > Teach __add_preferred_console() to update the existing slot when the > same console is mentioned again: we keep the original slot, but replace > its option string (and re-run braille option parsing) so that later > callers can override what firmware seeded. This keeps today's behaviour > unchanged for drivers, while allowing the cmdline UART parameters (and > soon the loglevel hints) to override the ACPI defaults. Another great catch! > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -2560,7 +2560,12 @@ static int __add_preferred_console(const char *name, const short idx, > (devname && strcmp(c->devname, devname) == 0)) { __add_preferred_console() can be called also after processing the command line, for example via the device tree: + serial8250_init() + serial8250_register_ports() + uart_add_one_port() + serial_ctrl_register_port() + serial_core_register_port() + serial_core_add_one_port() + of_console_check() + add_preferred_console Or a platform default: + hvc_rtas_console_init() + add_preferred_console() I would rather make sure that we update the values only when the console is defined on the command line: /* * Make sure that only command line is allowed * to modify the default preference and options. */ if (!user_specified) return 0; It probably won't have any effect. For example, of_console_check() calls add_preferred_console() only when (!console_set_on_cmdline). And hvc_rtas_console_init() does not pass any @options. But I would rather be on the safe side and make the logic explicit here. > if (!brl_options) > preferred_console = i; > + > + if (options) > + c->options = options; > + > set_user_specified(c, user_specified); > + braille_set_options(c, brl_options); > return 0; > } > } Otherwise, it looks good to me. Best Regards, Petr