linux-kernel - Re: [PATCH] USB: serial: ftdi_sio: Fix serial port stall after resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 27 Oct 2020 10:00:43 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Helge Deller <deller@....de>
Cc:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: serial: ftdi_sio: Fix serial port stall after resume

On Thu, Oct 08, 2020 at 08:16:02PM +0200, Helge Deller wrote:
> On 10/8/20 5:21 PM, Johan Hovold wrote:
> > On Tue, Sep 29, 2020 at 09:33:27PM +0200, Helge Deller wrote:
> >> With a 4-port serial USB HUB with FT232BM chips the serial ports stop
> >> working after a software suspend/resume cycle.
> >> Rewriting the latency timer during the resume phase fixes it.

> >> +static int ftdi_reset_resume(struct usb_serial *serial)
> >> +{
> >> +	struct usb_serial_port *port = serial->port[0];
> >> +
> >> +	if (tty_port_initialized(&port->port))
> >> +		write_latency_timer(port);
> >
> > Why are you only doing this for open ports?
> 
> I more or less copied it from another driver....
> 
> >> +
> >> +	return usb_serial_generic_resume(serial);
> >> +}
> >
> > And if the device has been reset there may need to reconfigured the
> > termios settings for open ports.
> >
> > Could you expand a bit on what the problem is here?
> 
> My testcase is pretty simple:
> 1. I use e.g. "minicom -D /dev/ttyUSB2". Serial connection works.
> 2. I exit minicom.
> 3. I suspend the workstation: "systemctl suspend"
> 4. I wake up the machine and wait a few seconds.
> 5. I start "minicom -D /dev/ttyUSB2" again. No transfers on the serial port.
> 
> With my patch the minicom serial communications does work.
> Another way to wake up the connection is to rmmod the driver and
> insmod it again.

Weird indeed. If you exit minicom before suspend and no other process is
keeping the port open, then that write_latency_timer() above would never
be executed.

Could you enable some debugging and provide a dmesg log from a test
cycle (open/close minicom, suspend/resume, open minicom)?

	echo file usb-serial.c +p > /sys/kernel/debug/dynamic_debug/control

Johan