On 11/03/2014 05:33 PM, Peter Hurley wrote:
Hi Kyösti,

On 11/03/2014 10:18 AM, Kyösti Mälkki wrote:
There are applications where it is desirable to not hangup ttyGS* when
USB disconnect is detected. USB host side of communication may
power-cycle periodically or there may be the actual need to physically
disconnect and reconnect USB cable temporarily.

USB disconnects on serial gadget are comparable to loss of Carrier Detect
of conventional UARTs. With the change, if ttyGS* has termios CLOCAL flag
set, disconnect on USB does not hangup the TTY.

Signed-off-by: Kyösti Mälkki <kyosti.mal...@gmail.com>
---
  drivers/usb/gadget/function/u_serial.c | 11 +++++++++--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index 491082a..dabc165 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -1253,9 +1253,16 @@ void gserial_disconnect(struct gserial *gser)
        port->port_usb = NULL;
        gser->ioport = NULL;
        if (port->port.count > 0 || port->openclose) {
+               struct tty_struct *tty;
+
                wake_up_interruptible(&port->drain_wait);
-               if (port->port.tty)
-                       tty_hangup(port->port.tty);
+               tty = port->port.tty;
+               if (tty) {
+                       if (tty->termios.c_cflag & CLOCAL)
+                               stop_tty(tty);
+                       else
+                               tty_hangup(tty);

It seems you missed my earlier email: what happens if you leave
out the stop_tty() call here?


Hi Peter

I did not miss it. My intro to the patch series says I am not familiar with tty infra, so I did not realize the question was directed to me. Also my setup with serial gadget runs kernel 3.12.6 so I cannot really tell or test if tty changes since that would make my patch invalid or unnecessary.

In the previous change for gserial_disconnect(), where the tty_hangup() call was added, commit message described it fixes an endless loop on tty device read and select. Would we be back at that situation without call to stop_tty()?

I ask because the tty is still restartable from userspace after you
stop_tty() here. So if your goal is to prevent write() from
happening, this won't work.

There was no goal to prevent write() on the tty device, should there be? Or should it silently just drop any characters while in the disconnected state instead of buffering (some of) them?

Thanks,
KM


Regards,
Peter Hurley

+               }
        }
        spin_unlock_irqrestore(&port->port_lock, flags);




--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to