What stops a parallel open or close changing ASYNC_INITIALIZED after you test and before you lock ?
Yeah, I should do the whole thing under the mutex.
Can you use test_bit() as well. I'm trying to gradually push all the code that way so people habitually use set_bit() and we don't get any (more) races where some compile situations and architectures otherwise create
load to register register ored with constant write back
Not related to this particular issue, but the fact that close() can powerdown the hardware is quite bad. Today it is always possible to use open,close sequence on /dev/ttyXXXX, and polling would break if close() deinitializes the hardware (e.g. via uart_change_pm()).
One of the long term goals of tty_port has always ben to have an object with the lifetime of the physical port so this kind of thing can be fixed.
In console= case, serial core handles the issue via uart_console(), checking if the port is used for console, preventing it to power down the hardware. We can do the same, or make tty_find_polling_driver() refcount individual ports/lines. But the issue is orthogonal to this particular patch, although needs to be fixed some day.
Agreed - however you'll need a separate refcount than the main tty one for this, because we still need to do a hangup() on the final "tty" close even if the hardware is 'pinned' for a debugger.
Alan