> > > My understanding of locking in tty layer and it's subdrivers is not so deep > > > so I did not dare to change something in that - it might be that checking of > > > serial->disconnected would not be needed in option_send_setup() nor in > > > usb_wwan_dtr_rts() if the protection via hung_up_tty_fops would not > > > leave a hole in tty_open/tty_release. Maybe the proper fix should be > > > done somewhere in tty_release/tty_port_close_start/tty_port_lower_dtr_rts? > > > > You may very well be right about that. A good indication would be if > > other serial drivers have the same sort of potential race. > > > > Also, wasn't the DTR/RTS stuff modified just recently? > > Well tty-core shouldn't handle disconnect (which is usb-serial- > specific) Just to clarify: the tty layer could learn to deal with disconnect (useful also for cdc-acm for example), but currently it is handled in usb-serial core so moving it there first for dtr_rts makes sense. > but I see no reason not to move the disconnect handling up to > usb-serial core. It does not make sense for usb-serial drivers to > manipulate modem control-signals after the device is gone. Might as well > deal with in core as we do for open. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html