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
