Hi, On Mon, Oct 24, 2022 at 3:46 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Wed, Oct 19, 2022 at 7:56 AM John Ogness <john.ogness@xxxxxxxxxxxxx> wrote: > > > > Replace (console->flags & CON_ENABLED) usage with console_is_enabled(). > > > > Signed-off-by: John Ogness <john.ogness@xxxxxxxxxxxxx> > > --- > > drivers/tty/serial/kgdboc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/tty/serial/kgdboc.c b/drivers/tty/serial/kgdboc.c > > index e76f0186c335..b17aa7e49894 100644 > > --- a/drivers/tty/serial/kgdboc.c > > +++ b/drivers/tty/serial/kgdboc.c > > @@ -533,7 +533,7 @@ static int __init kgdboc_earlycon_init(char *opt) > > console_lock(); > > for_each_console(con) { > > if (con->write && con->read && > > - (con->flags & (CON_BOOT | CON_ENABLED)) && > > + (console_is_enabled(con) || (con->flags & CON_BOOT)) && > > <shrug>. I guess this is OK, but it feels a little pointless. If we're > still directly looking at the CON_BOOT bit in con->flags it seems > weird to be accessing CON_ENABLED through a special wrapper that's > marked as a `data_race`. In our case it's _not_ a data race, right, > since this function continues to hold the console_lock() even at the > end of the series? I personally would drop this patch but if you > really want it I won't object. I realized that my statement isn't quite true. It actually only holds console_list_lock() even at the end of the series. Still, it seems weird that we're declaring the `data_race` on CON_ENABLED but not CON_BOOT ?