From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 99E7048B367 for ; Wed, 15 Jul 2026 15:52:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784130753; cv=none; b=LW4NeHg1l5hOpbuE+7u/8dkcSSuOV6bNM7AuleF8D5DVgve9lnIT31Al4PqY5eNLa6qU+XMz749ncyc/ouLu1E/C3HpYLcYjvQy4cKcKy547CRP6ZvIl0FOF90RmJKsQ2U/FbGkNcvCWy6B7bhoz6kKRyrGVJhD6Cl/ZY5lxGLk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784130753; c=relaxed/simple; bh=9I7tjrQCdRCxIStIEtG2Dfr8lEL3nyDjeyygbw1URDE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ivBZaSRSX7ZheEsXgxSWKhVIqZUd5A2RKa6BRzaDxzPgr34/NdBKb0hRS6R/wJR8Zs6mubcJJXGjGDBFx4TM0bajUGDQAQvRS/k8sndOlN8GiiVwiYQ5IN6RE8fgu3Tc9HhCYgzgXGOgofEUXn9P3hCS9CLWWHsCHytRJGEnLiA= 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=MCAvanmU; arc=none smtp.client-ip=209.85.221.47 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="MCAvanmU" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-47de008b020so1216221f8f.1 for ; Wed, 15 Jul 2026 08:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784130748; x=1784735548; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=K4nAmWmLCd2HQoy7dO3H3jp2xf3fqchq7sLL+NvHfos=; b=MCAvanmU185fEa3y3utkosVZ/C2HTbL2nAEiDjF/svlERhftsNnI91hdI99R35BYGs SCGtvZIKsIaafjyfnE7+aM8AF2CvmM9G9E4Tglr4T6ZkJcpNiPt8L7LF5q2OXvD9bvZy bgggfwyiDAkTyTS1t5wylXxUNw/3vlKKLfonmdoai+pURg/VQoiEvbZqukWmun8soA9m oN+9fd9+x193M/eEF7LRMKRisrtswHS0Ed2YBqyGGJYQGuNpCj6pT6qHSNykqX7a6jRZ Qq2AVetcNAPn38up49CWwgtFwh9blJdySd+BEhl0gq+Qc7QfokJaf083pvt4oUn7NyQB IMFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784130748; x=1784735548; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=K4nAmWmLCd2HQoy7dO3H3jp2xf3fqchq7sLL+NvHfos=; b=em9Ejc4rnmMeM1NEnammsJZ53o0+IWFkyvnraW0NgyDgY9QD+GAHEghR/mVjfWoEaK AkmT+27Fv9ZPcGe8ydFl9EapLW/b7/SYqnF/CmF4qEziV8eHQ0c2eqCrMsc6NqRSk4Xz NwNoWckPmkpIj7DO+NfMwg9lLOQeQFEFstxdwRi7I60Sp9uY0Y3FJ0CrOIdpAfea9Y3x mlsIgcrbbsO0G93wAikuoQB2Lw4hNMHfZj/GMCG61gDiNe4z0TeS8486Xs3OEdW1Sykj BgyqA6EqvhtvbHcrSbPeVBSvJj49eOtNZjZ88c5t+sbDcxtlX6pnnGKLGRKqUCCNlU/F IFhQ== X-Forwarded-Encrypted: i=1; AHgh+Ro/5W5Q32xJCJ+hNlMESFoTiC+brUhy+uQvnrHnERiEH3BhTBWyLP7Q0g+tF1mV+GIAVzNET8aPoXeMibo=@vger.kernel.org X-Gm-Message-State: AOJu0YzGiussvbL0kH6cv5Y7eEdsAfGvu5F8NMp0hCwdL1szsKJw5Lhr m6Nvnla+phCVcFCcE38OUtAngRQyE9U3pUDNQEFnb887H0TerS4k2+2KoRj+lE0gM/M= X-Gm-Gg: AfdE7cmXekq1gX6S8pI10kkhTR1DxgjrWGr1FuFwB0jpxFkSgK4LJ9fQvBN4dTP1Vn1 8D9TnfZ+wn5EQwEWsLjtHE6C6OwF2KxUxIo8feTVuF4L31iToH3PI2JFIyGlA78tZi/uJzi8FAZ vUnm3fVS8aK6v60XVbeZaH81Z+TT1NdvyD/0FGr813O7RMgfSnxcNVYMc+T0UCws/kZUS66yxUJ zkTT3rCxLmvTn+bOYdZIKSIOCZAkHPoCo+iy2rJojXZclN5aO9EvXLEHL7m72AmxCzvG2307V1W f3KHEARN/VeL2WYDzZhCqipR7jO+TsiuO8JE9cyeloIXefAf4EVfHMXkmpKZi8HaWkm+aJzl+vX SGLrqs12jMqpiCyZaTBWuHCDez/VLsHCVBSCc4FqPP2ow68WT9qHjU4WBX42/Yd8/+TRX/ENO// N9KZ45nDfFA9wxguU= X-Received: by 2002:a05:6000:22ca:b0:470:b344:22e3 with SMTP id ffacd0b85a97d-47ef697ee3dmr27879487f8f.18.1784130748551; Wed, 15 Jul 2026 08:52:28 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f4829896asm15458357f8f.23.2026.07.15.08.52.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2026 08:52:28 -0700 (PDT) Date: Wed, 15 Jul 2026 17:52:16 +0200 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Steven Rostedt , Marcos Paulo de Souza , Chris Down , Naveen Kumar Chaudhary , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 04/11] printk: Separate code for adding/updating preferred console metadata Message-ID: References: <20260604101459.393162-1-pmladek@suse.com> <20260604101459.393162-5-pmladek@suse.com> <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; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o6g9bpwm.fsf@jogness.linutronix.de> On Tue 2026-07-14 16:41:05, John Ogness wrote: > 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. Good point! > 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. Hmm, this patch was supposed to define some sane rules. For example, options defined on the command line would be used even when the same console was first added, e.g. by SPCR code without options. Or at least it looked ugly to keep the original behavior. But maybe, it was not that good idea: + It is always a bad idea to "hide" behavior changes into a patch which primary does "just" a code clean up. + We need to be careful when adding new rules. And it might need longer discussion. I am going to keep the original behavior in v5. And likely even leave the behavior change for another patchset. Best Regards, Petr