public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-m68k@lists.linux-m68k.org
Subject: Re: [PATCH printk v2 06/38] tty: nfcon: use console_is_enabled()
Date: Tue, 1 Nov 2022 09:57:26 +0100	[thread overview]
Message-ID: <Y2Dfdje2x34VvWMb@alley> (raw)
In-Reply-To: <87fsf49e6d.fsf@jogness.linutronix.de>

On Mon 2022-10-31 17:05:54, John Ogness wrote:
> On 2022-10-21, Petr Mladek <pmladek@suse.com> wrote:
> >> diff --git a/arch/m68k/emu/nfcon.c b/arch/m68k/emu/nfcon.c
> >> index 557d60867f98..c542fc2b121f 100644
> >> --- a/arch/m68k/emu/nfcon.c
> >> +++ b/arch/m68k/emu/nfcon.c
> >> @@ -151,7 +151,7 @@ static int __init nfcon_init(void)
> >>  
> >>  	nfcon_tty_driver = driver;
> >>  
> >> -	if (!(nf_console.flags & CON_ENABLED))
> >> +	if (!console_is_enabled(&nf_console))
> >
> > Heh, the check of CON_ENABLED does not make much sense. IMHO, the
> > important thing is whether the console is in console_list or not.
> >
> > I would personally add a check at the beginning of register_console()
> > whether the console is already registered and enabled() and do
> > nothing when already done.
> 
> Actually, register_console() already has this check, but it does a
> WARN(). If the debug setup is used for nfcon, this situation is
> normal.

I see.

> So probably to avoid the WARN, the CON_ENABLED code was added.

I though more about it. I would keep the warning for the case
when the 2nd registration is not intentional.

This driver has two ways how the console can be registered.
It can happen either in nfcon_init() or in nf_debug_setup().
It is better to have an explicit check to show that it is intentional.


> > I would be nice to fix this. But it might be done later.
> 
> I could add a console_is_registered() function that checks if the
> console is in the console list and use that instead. If we are going to
> touch this code, we might as well touch it correctly, right?

It would be great. It is actually much easier after switching
to the hlist.

Best Regards,
Petr

      reply	other threads:[~2022-11-01  8:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 14:55 [PATCH printk v2 00/38] reduce console_lock scope John Ogness
2022-10-19 14:55 ` [PATCH printk v2 06/38] tty: nfcon: use console_is_enabled() John Ogness
2022-10-21  9:55   ` Petr Mladek
2022-10-31 15:59     ` John Ogness
2022-11-01  8:57       ` Petr Mladek [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=Y2Dfdje2x34VvWMb@alley \
    --to=pmladek@suse.com \
    --cc=geert@linux-m68k.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox