All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Junxiao Chang <junxiao.chang@intel.com>,
	bigeasy@linutronix.de, tglx@linutronix.de, rostedt@goodmis.org,
	linux-kernel@vger.kernel.org
Cc: hao3.li@intel.com, lili.li@intel.com, jianfeng.gao@intel.com,
	linux-rt-users@vger.kernel.org
Subject: Re: [PATCH 0/2] nbcon locking issue with v6.6.10-rt18 kernel
Date: Wed, 24 Jan 2024 10:46:44 +0106	[thread overview]
Message-ID: <87o7db9ihv.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20240123054033.183114-1-junxiao.chang@intel.com>

On 2024-01-23, Junxiao Chang <junxiao.chang@intel.com> wrote:
> There are two serial port devices in one Intel ADL hardware, one is
> 8250 lpss, another is 8250 dw. Multiple uart devices are enumerated as
> ttyS0, ttyS4, ttyS5,... With 6.6.10 rt18 kernel, booting hangs in
> nbcon_release if console is enabled by appending
> "console=ttySx,115200n8" to kernel command line. According to nbcon
> author John's suggestion, lock flag is moved from console structure to
> uart_port. Another patch is to add uart_is_nbcon checking in
> nbcon_release.

Isn't the real issue that the console pointer is copied to device that
are not consoles? I am wondering why that is. Is it possible to
dynamically switch the console index during runtime? If not, I think a
proper fix would be to only assign @cons if it actually registered as a
console. This would also simplify the uart_console() macro.

It is critical that a struct console is not shared by multiple
devices. I do not like the idea (or see the point) of having non-console
devices store a struct console pointer that is registered with another
device.

I will take a closer look at that.

John

      parent reply	other threads:[~2024-01-24  9:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17  6:52 [PATCH] printk: nbcon: check uart port is nbcon or not in nbcon_release Junxiao Chang
2024-01-17  8:23 ` John Ogness
2024-01-17  8:45   ` Chang, Junxiao
2024-01-17 10:03     ` John Ogness
2024-01-17 10:24       ` Sebastian Andrzej Siewior
2024-01-17 13:08         ` Chang, Junxiao
2024-01-17 13:42           ` John Ogness
2024-01-23  3:05             ` Chang, Junxiao
2024-01-23  5:40               ` [PATCH 0/2] nbcon locking issue with v6.6.10-rt18 kernel Junxiao Chang
2024-01-23  5:40                 ` [PATCH 1/2] printk: nbcon: move locked_port flag to struct uart_port Junxiao Chang
2024-01-24  9:47                   ` John Ogness
2024-01-24 10:05                     ` Sebastian Andrzej Siewior
2024-01-25  1:08                       ` Chang, Junxiao
2024-01-25 13:35                         ` Sebastian Andrzej Siewior
2024-01-25 23:20                           ` Chang, Junxiao
2024-01-26  7:58                           ` John Ogness
2024-01-26 16:39                             ` Sebastian Andrzej Siewior
2024-01-23  5:40                 ` [PATCH 2/2] printk: nbcon: check uart port is nbcon or not in nbcon_release Junxiao Chang
2024-01-24  9:57                   ` John Ogness
2024-01-26  2:33                     ` Chang, Junxiao
2024-01-24  9:40                 ` John Ogness [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7db9ihv.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=hao3.li@intel.com \
    --cc=jianfeng.gao@intel.com \
    --cc=junxiao.chang@intel.com \
    --cc=lili.li@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.