From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 5D2382F7F1E for ; Tue, 14 Jul 2026 14:35:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784039708; cv=none; b=KPEL2xC3aMEmIZCPf8zusgWAVB36/hHd6tUqeSrSLCwICf8vjrAqIzojqyGxisXmRyOt9ZvqqzmVTtNO9nh1ZEReLLmi7heCYsQu0Z2OBlySHIPJ7j62fs0AQ+L9egkSXYKlEec0ZoOPMcX1Z8SGY9E3tZZ30YkZTOLXoK2wcIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784039708; c=relaxed/simple; bh=HfbH9TmvGhwyXM5o3ct+EJYBZdSqMoM4ct4lq34kygI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hGJ5CmOVPeER/OyBZwD6LhmV5uTgin4jc8GMf93W1XGRzNO9rCSYfxYlOjnQKG2m13Na/SpxpoFCFEn/z8Eguc0ztkMhaQMaoHJpWi95wVOeZhz7vs4eJuHQlpbAYyLyQ465jQunD0wOiCq1MrH4IQxmn1lNm7xkJLVCgPGz0SQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=b9SOPD/s; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=TPUFaufN; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="b9SOPD/s"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="TPUFaufN" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784039705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xf02Xtf0yjFahtx0xhsN2GvGdepupcqvwkbqxs5p3TY=; b=b9SOPD/svsLOkcPjgSdpmP+qYG2aB8kalyxtKTmPFxC8tXibPMRPviqOINgwwqAtNijb/3 0P7yiuahn3kDKWfgRyQL0jSlzja/tSX3Art7RqxG5mZ2+PvLWlNsPtHcPWLZRyXxK/GU1c AQDGau/ULrAzaaoVeZjn9fP8jnGMoJmeeB99pvofVvag6v3yqjHG8/oBXJHhxnoq/38mno zM/ziGWA/Dqy9emoDCCLNaIS/C3sa2meSasDimD6llq0e5Uc91l3ezb9WBwowEeYTJY+41 Nlq5WYL6SrDESgS1zzFAlqu5Se9beuWaEIeY68ym0CQxQsACVPcZp64M5EgbFA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784039705; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xf02Xtf0yjFahtx0xhsN2GvGdepupcqvwkbqxs5p3TY=; b=TPUFaufN7ck6BZyM+Jr5PADVKjRjnKnXNY3k9lx8DRbWod+oP/8BX+IuHFSL+pZn991CLQ hQNIDYyvj0tsOzDA== To: Petr Mladek Cc: Sergey Senozhatsky , Steven Rostedt , Marcos Paulo de Souza , Chris Down , Naveen Kumar Chaudhary , linux-kernel@vger.kernel.org, Petr Mladek Subject: Re: [PATCH v4 04/11] printk: Separate code for adding/updating preferred console metadata In-Reply-To: <20260604101459.393162-5-pmladek@suse.com> References: <20260604101459.393162-1-pmladek@suse.com> <20260604101459.393162-5-pmladek@suse.com> Date: Tue, 14 Jul 2026 16:41:05 +0206 Message-ID: <87o6g9bpwm.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 2026-06-04, Petr Mladek wrote: > The logic for adding or updating a preferred console is currently > duplicated within __add_preferred_console(), making the code difficult > to follow and prone to consistency issues. > > Introduce update_preferred_console() to centralize the initialization > and updating of struct preferred_console entries. This refactoring > explicitly defines and enforces the following rules: > > 1. Console names and/or indexes are not set when a console is preferred > via devname; these are resolved later during device matching. > 2. Console names are only added alongside a valid index. > 3. Only matching entries are updated. > 4. Console and Braille options are never cleared. They are updated > only via the command line. > 5. The global 'preferred_dev_console' index and 'console_set_on_cmdline' > flag are updated consistently. > > Additionally, rename braille_set_options() to braille_update_options() > to better reflect its conditional behavior. > > Behavior change: > > The original code never updated the preferred console options > when it was preferred more times, e.g. via the command line > and/or some platform specific code, e.g. SPCR or device tree. > > The new code explicitly allows to update the console options > when they are preferred over the command line. > > It mostly worked even before but only because the command line was > processed early enough before handling SPCR, device tree, or other > platform specific init code. As you previously mentioned, this is a recipe for regressions. IMHO the real issue is not that the behavior is changed, but rather that there is no official ordering for SPCR/DT/command-line across all platforms. Also, although a later specification can override previous options, it cannot clear them. I am just wondering if the previous behavior should be preserved until someone implements a full solution with proper official option ordering and override capabilities. John