Re: [PATCH 03/13] serial: don't use uninitialized value in uart_poll_init()

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

On Thu, 8 Aug 2024, Jiri Slaby wrote:

> On 05. 08. 24, 17:46, Doug Anderson wrote:
> > > > @@ -2717,10 +2716,10 @@ static int uart_poll_init(struct tty_driver
> > > > *driver, int line, char *options)
> > > >                ret = uart_set_options(port, NULL, baud, parity, bits,
> > > > flow);
> > > >                console_list_unlock();
> > > >        }
> > > > -out:
> > > > +
> > > >        if (ret)
> > > >                uart_change_pm(state, pm_state);
> > > > -     mutex_unlock(&tport->mutex);
> > > > +
> > > >        return ret;
> > > >   }
> > > 
> > > This too needs #include.
> > 
> > Why? I see in "mutex.h" (which is already included by serial_core.c):
> > 
> > DEFINE_GUARD(mutex, struct mutex *, mutex_lock(_T), mutex_unlock(_T))
> > 
> > ...so we're using the mutex guard and including the header file that
> > defines the mutex guard. Seems like it's all legit to me.
> 
> The patches got merged. But I can post a fix on top, of course. But, what is
> the consensus here -- include or not to include? I assume mutex.h includes
> cleanup.h already due to the above guard definition.

Yeah, while guard() itself is in cleanup.h, Doug has a point that 
DEFINE_GUARD() creates a guaranteed implicit include route for cleanup.h. 
Thus you can disregard my comment as it seems unnecessary to include 
cleanup.h.

-- 
 i.