> diff --git a/drivers/tty/serial/serial_core.c > b/drivers/tty/serial/serial_core.c > index 9c4c05b..0dc246d 100644 > --- a/drivers/tty/serial/serial_core.c > +++ b/drivers/tty/serial/serial_core.c > @@ -1284,6 +1284,8 @@ static void uart_close(struct tty_struct *tty, struct > file *filp) > uart_wait_until_sent(tty, uport->timeout); > } > > + state->uart_port->closing = true;
So what are the locking rules for this - when is it valid and when can it be tested. This also still seems a hack to me - the core tty code doesn't have suspend/resume/open/close confused. The uart layer does, so really the uart layer needs untangling. I'm skeptical yet another magic state variable is the answer, particularly when the locking model for the variable appears undefined. Teach the uart core code to pass an extra argument indicating whether its really doing shutdown/open or merely doing suspend/resume. It's perfectly sensible that it tries to use the same helper for both, its broken that the called code cannot tell which. The parameter would also be a local variable which avoids all the locking questions. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
