From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 0102119D093 for ; Fri, 20 Feb 2026 04:52:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771563134; cv=none; b=ROtBRTizWD0ti+zl2nnlR92bIVE7Lbl20kR4Kb8G/MDF+iiQw8rqsb6M2uVYyTS7tvPDX2LMZBjqjSx53SmtxrlPtkrqN3GGbhcOPiu2FZNIyeiNBnxXrPGsqkDga5MnZovMEwmvBWyleSorcvELGOlhAVSjDyyhKg8iDoSv48g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771563134; c=relaxed/simple; bh=+6u0bHXEX2+vCPimDJsbXuPLst0z4VsAmOekpMGL1bI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Zada2WM1PtYpiqTHJhGLlOUmiorkRp1Qh+Zn9nw3iLwW/V1HHcEwja2oYKxH+UjSHwVr8cGAkV9fT+N4+2lj1EV/qlTJqAXWBJvAPp+R5HP8/ltOCtILLI2t++iTY2MYfv28O6nj6uNj0WoV1zKDjQmtYhXWGdxzqmFxc03HY/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=chrisdown.name; spf=pass smtp.mailfrom=chrisdown.name; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b=ejZiqFJR; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=chrisdown.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chrisdown.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="ejZiqFJR" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2a7a9b8ed69so15664765ad.2 for ; Thu, 19 Feb 2026 20:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; t=1771563132; x=1772167932; darn=vger.kernel.org; h=user-agent: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=oJAhAer3kcHKnbYxgO/g6o1kiXtyEGCYLUfEJ84ALb4=; b=ejZiqFJRRTe/d9mIeHxPgvIbJGi1cn6SMLjYywT25bjWiAM7RnBRSA4yDxvgvn/l/C 6xsxq2yu4hL9syq2KD13gmr2U1eduQud70mrr9gOM1QcvjBkY9i8lgteFpfE5Z7Ayztd Ir0Pc8bGqlLeT/vUcpsd2IOAr5u1uk/4GDfBU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771563132; x=1772167932; h=user-agent: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=oJAhAer3kcHKnbYxgO/g6o1kiXtyEGCYLUfEJ84ALb4=; b=oYfdYI5oUPnHtSgCor8JO7Ax17ACDc9NzovIVbIAJEnUCj2ja1QGseclj8T9MUMfNh mp3+FpPBFahZfqDfutu6oqnJpKrHkFqQWepdVhrmpWYoqpKDH/qjcNCEV/ZO+nG+3h+q dDv9Xab5yZpEUQctpoMnG7m7wHRnIh3FIokp/SkvHsAhktIyDZazT56h1QHAzE8zqaym AVt38QLsqr6Y9QxvylbePogMdrU6VMFDwvSrK0Y6zIkBRrPIj36d53GyjAUC0xmZy/XO s34CDH3tsu3n6OW0qOGTbaVbO5b0Zy1vNrfdGWrC14GgLNMMP0wfSWRDxpEcVglQ/u0P 0RkA== X-Forwarded-Encrypted: i=1; AJvYcCUNJxc2nYlrq2e44jU2MMMqp7ZIKOP74K095pOP6hdbv+vYBCOKhXFhu53ffBYHY3LHAB4eWpbzAG36qQE=@vger.kernel.org X-Gm-Message-State: AOJu0Yw7W0Sx8E2aDN9T4DhtsKi7hOlmC22GxHncysETwCXRCPdSjvSO OugrXuXfoswNNi9qUL/n2VRsJC9OCKXtP4pxQN6bE5jA2PiTtRQ21PNKd3O7OAMtPRs= X-Gm-Gg: AZuq6aJU4s6V1zNdUNkDKbALftRXhI9x7fZKUvwBmuOFJGnER/Y88D+LZC1GN6AhnpL LPuPoRShJEoOFea2qGqoYJJu2RGFPdVMl9oxqtLb/awK66NolsE3ebGVpZZYlJM31ydqu0Ri11/ knMTkjQskg9+kSxMa0VGO6VjqUODGFXbBlFz05FqrCSaK7LdTdN8KjClXK90CdRCoAurpS/DcnC O0bxpCQ7+n4l9htPVkGeuHP5qyZ53U6oXW7PjCIp8Sd3mP5BXWZQNiWFLgC0+AHEuHdA/qtI7EA o9pNq/hh8oL836yAu/re4kR8hh3KVldqpmxOx/6Ax6qXJOosz8xv48Mqb+f3w93mT+kCc1/BhXx 2CcfsfrsilqnCsi3cn2vsACzvlq/NltJvY+2sZ69xorrYOf4RzQT6bA5CaS90Tdg/ssQXOwhhlN 91A+srLNO5TmakuodYi0XXYKN66CqFK6o= X-Received: by 2002:a17:902:d512:b0:2aa:fad8:7474 with SMTP id d9443c01a7336-2ad50f340c2mr70046695ad.33.1771563132242; Thu, 19 Feb 2026 20:52:12 -0800 (PST) Received: from localhost ([175.139.248.66]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad1aadce38sm187300145ad.71.2026.02.19.20.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Feb 2026 20:52:11 -0800 (PST) Date: Fri, 20 Feb 2026 12:52:09 +0800 From: Chris Down To: Petr Mladek 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; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.15 (2b349c5e) (2025-10-02) 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. 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.