Jiri Slaby writes: > > On 03/13/2013 02:46 PM, Bill Pemberton wrote: > > Jiri Slaby writes: > >> > >> tty->ops->break_ctl cannot be called outside the gap between open and > >> close. So there is no need to check whether the port is open in > >> break_ctl in quatech2. Remove the check and also that member > >> completely. > >> > > > > We can't get rid of is_open. The devices use 1 read urb for all ports > > and will send various things about ports that haven't actually been > > opened. So the driver needs to know if a port has actually been > > opened or not. In fact, I was about to send a patch that fixes a > > warning caused by commit 2e124b4a390ca85325fae75764bef92f0547fa25 > > causing the driver to try to write to ttys that weren't actually > > opened. > > As long as tty_port exists for the port, calling tty buffer functions is > OK. The warning you mention is now bogus and there is a patch flying > around to disable that at the moment. >
Ah, ok, I assumed the warning was telling me the driver was doing something stupid by calling tty_flip_buffer_push() on a port that wasn't opened (which did sound like a stupid thing to do to me). If that's actually harmless, then yes, the is_open stuff can be dropped and my recent patch to check is_open before calling tty_flip_buffer_push() can be ignored. > It is also that is_open was completely racy, right? > Does it simply need a lock around it or is there something else I'm missing? In any event, if it can go, that's great -- it's only used for the above "don't call tty_flip_buffer_push() on an unopened port" logic. -- Bill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
