From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 7FEE8337BB3 for ; Fri, 20 Feb 2026 11:44:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771587864; cv=none; b=opNiBL9ulivH6kd701aW5ooCLzWgpjnU+HZMVFpwD2+cFGUeo3Zy1HxSjlnlZzXR0X0qvS5DQxyMpr45YhGMjhTITVySktFbMb1AZoFMdgUAmM1Xtt+ruOyWjQhK7voj1HJkAlf7xyJJ3vvexd9ISrkPphX4ODlg0XWEto5Elvk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771587864; c=relaxed/simple; bh=3dPvABbWCziF7DPS2YkUHcceJ5t+RWBAjAajzPDVLZI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JB72HlIZ9udZ6SkAKYTtzH2ZrsGwWZlhrTcUC6Vuk00ECq03E3HJUA/O89SlB8+pxd5AiamMAnKnokmBKNvtAKp9NH8W/hRtqsxkEvqQRFniQQmMMV3RI8Q2JKmbORhnXVONV3G1ZQgrMrVcHK4In9ZluT/GqQC8RHX7aqbrr74= 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=ZFSDsQ/V; arc=none smtp.client-ip=209.85.128.50 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="ZFSDsQ/V" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-483a233819aso15554525e9.3 for ; Fri, 20 Feb 2026 03:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771587861; x=1772192661; 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=rmqg8s+Arw7umfHKoYSaksz3c+7EfifF9Ei+Czav7DY=; b=ZFSDsQ/VWAde5sBWAf5QzZytbpRhqIfoEGMrKs7eXjyjFlhyzwISJIMH81dh7zTwMp ClA0OvRUJ3rGnsK6itkBhLlM9daSqa7GDDeRqy9/3XdTVgLKISYeNyTe3cFw5VXaYZY1 tI8NX2lJwAFVcwTnABkvQl8yxc/64HdJ6RGOOSneUK795eIdX08rfejs5Pw9CokLBQzx uu3ppmtww/bk9Cfia+5LG9v43nZya48Hu0FAYF2wzVKedzP1j55YbXYPo9FAUVXpqbgL 4khKsUqIYazIhXoTlP0xyMoKCzK8MfAuiCP6Wg+8vFq2jrMEmYb0EypFjCnlYgY7ki4d vreg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771587861; x=1772192661; 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=rmqg8s+Arw7umfHKoYSaksz3c+7EfifF9Ei+Czav7DY=; b=grcI4KTqLbGcj4KNPo/fEtwNyYbdUPT4N20Uv2qlqGZkpvJE/e0TL71yNNHQepTuJg Xs9L2B30bgEvlI0LhP6iIqtwFwdBs6ZiB2VdH29jvipk7Vh52G/QuhM2KD9I88YPVi+3 mb+KbZepn0nwuKEXu8wVk4vmHshP31VoZc0JcDQAPjR2bDwvqS87uSH6vv0cNLaV7iqw 4RvhovocimNKZ3RYkgQMeEDLGR6zGeiClGac61bhgWoW4w8fyvzGSig3DXOKv+Ts6jRU jXn6wweKMgcMVlqMzznftqw6lrHvdMWTDmY1tB+GUNVjuShbH36WPw+742hOnu0nziwM sQSw== X-Forwarded-Encrypted: i=1; AJvYcCWnJYKdBzpE9+bbXjkIzlqokOtgUAqa3HU4gI2DjdzSyqRozGv9mk9yAJtBWdo3TNuevWjUX08eLxzMxpM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz9rjYlC1+YSx/7AqfyPHoVYkzPCwcP2kEl+IdTp+jRNfkRfFcn 8zxab1eetzDPIlRZOPC9UHTQiMgsiSNscBlKoLbHnygVOLDpTQ2hN2I6lPXSNANitutAGFaIRm9 F71SQ X-Gm-Gg: AZuq6aJFeufyKJQ3xzPqR2B9vRpGhVE2Of4nxLGVGoQzkkPiRbk6ax+74iRXNkpKrL1 fpsKVvtFnZlHDIqo0DC6tVMs8tzmi3OR1GxYgQGlA+DZvqEvUIIO2W1jQwdi5aBYpWXL58Tc5mk ZuGiYRfZd6PpVLgExaSLWW6Fz0YGGa0lkukzHNvPc2nLS+O9mYnQ9EPdi409H48n87tIm8X92vz dZmCrelkCIY3u8UiH+tT4pVulVOmo9YVZzobTtNMxOk1Rk0MRyKk+hgvuvKeisQlbfNf7SlBSK4 csfyA6s90m4yH81QPFgNzRECIGiJHR7ZWXqLrdAoWfPRs3fJO3A4kiLNSIO4Sl/Vhz01hFMyuZp I03ctw7q4dbX+gBiGpuGmTW7tg1o42ccTCujYuhGj56TocPhgP8+stUfiAOwh/ToW0HYnb5BHYe A4NCvzsdO+e8cO7z13GNKltsKT2D46CSQsukfm X-Received: by 2002:a05:600c:310d:b0:47e:e57d:404 with SMTP id 5b1f17b1804b1-48398b0acdcmr172944715e9.16.1771587860688; Fri, 20 Feb 2026 03:44:20 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a31d3ebbsm63293335e9.13.2026.02.20.03.44.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Feb 2026 03:44:20 -0800 (PST) Date: Fri, 20 Feb 2026 12:43:20 +0100 From: Petr Mladek To: Chris Down Cc: John Ogness , Sergey Senozhatsky , Steven Rostedt , Marcos Paulo de Souza , linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/8] printk: Try to register each console as Braille first Message-ID: References: <20260206165002.496724-1-pmladek@suse.com> <20260206165002.496724-6-pmladek@suse.com> 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: On Fri 2026-02-20 12:52:09, Chris Down wrote: > Petr Mladek writes: > > > The try_only_braille and is_braille_console_preferred(pc) checks likely need > > > to happen before or independently of the match() vs. default matching > > > branch. > > > > This should never happen because register_console() always tries to > > register Braille consoles first. > > I think maybe we're talking a bit past each other :-) It does seem I > misunderstood the ->match() semantics a bit though, I don't think there's a > bug here any more, but maybe worth a clarifying code comment. > > My concern wasn't so much about the ordering between > try_enable_braille_console() and try_enable_preferred_console(). It was more > about what happens inside __try_enable_preferred_console() when it takes > try_only_braille=true. _braille_register_console and > is_braille_console_preferred are both inside the default match block, which > is only entered when ->match() returns non-zero or is absent. So, if > ->match() returns zero, both would be skipped and the console would fall > through to CON_ENABLED without _braille_register_console() being called. You are right. I have completely missed this variant. > But looking more closely I don't think this can trigger in practice as the > tree is right now. The only ->match() callbacks in the tree only match > earlycon-style names, and always return -ENODEV for other kinds of inputs. > So actually they return -ENODEV in this case and we enter the match block > normally. > > But I still feel like maybe the structure is a bit subtle here, this > confused me. The correctness of the Braille path seems to depend on > ->match() never returning 0 for these kinds of console names, which I'm not > sure is documented or enforced anywhere else. Maybe a comment mentioning > this would help future readers? I won't block on it though. You are right that these are subtle checks. Hmm ,we might call __try_enable_preferred_console() three times and we are always interested in some particular entries: + Braille consoles + User specified + Platform specified I agree that we should distinguish this in the main loop. I am going to add the following into v2: static int __try_enable_preferred_console(struct console *newcon, bool user_specified, bool try_only_braille) { [...] for (i = 0, pc = preferred_consoles; i < MAX_PREFERRED_CONSOLES && (pc->name[0] || pc->devname[0]); i++, pc++) { /* Console not yet initialized? */ if (!pc->name[0]) continue; + + /* + * @try_only_braille and @user_specifified define which + * preferred console entries are handled in this round. + */ + if (try_only_braille) { + if (!is_braille_console_preferred(pc)) + continue; + } else { + if (pc->user_specified != user_specified) + continue; + } + if (!newcon->match || newcon->match(newcon, pc->name, pc->index, pc->options) != 0) { /* default matching */ [...] But there is still the problem that there might be two entries with the same pc->name. The 2nd entry might appear later when pc->devname matches, see match_devname_and_update_preferred_console(). I am afraid that the same HW device might get registered as both Braille and non-Braille console. I though about catching this in match_devname_and_update_preferred_console() and returning -EBUSY. But there is similar problem that another entry might match also via con->match() callback. But maybe this is not a problem at all. The above proposed check and calling try_enable_braille_console() first ensures that the Braille entry is preferred. And each HW device should get associated with a particular "struct console". The subsystem should make sure that it does not register the same "struct console" twice. Maybe we could check console_is_registered_locked() at the beginning on register_console() to be on the safe side. Best Regards, Petr PS: I hope that the above makes sense. My head is spinning a bit now. And I am leaving early today for a week long vacation which affects my concetration a bit... I think that I need to make more tests after I am back.