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.
