[PATCH] serial-port: fail open/reopen after a serial port is disposed

[Dan Williams]

On Sun, 2014-01-12 at 19:00 -0800, Ben Chan wrote:
> >
> >> Related to the HUP case, is the port always removed by the kernel?
> >> I sometimes observed that ModemManager was able to communicate with the
> >> modem after restarting. so I wonder if the 'port hangup' scenario is temporary.
> >
> > If the port HUP happens, we force-close and we actually just assume
> > we'll get a udev event to get the port removed. Not sure if we can
> > consider those as temporary failures; as the port will get re-plugged
> > and re-notified by udev, which will trigger a full new port probing setup.
> >
> 
> Aleksander and Dan,
> 
> We've seen a case where, after the serial port was forced close upon a
> G_IO_HUP, no udev event was issued to remove the port. Indeed, the
> port seemed to function properly if we allowed it to be reopened. I'm
> wondering if that's an expected behavior (i.e. HUP doesn't always mean
> the port is removed) or a bug in the kernel ACM driver or the modem.
> If it's an expected behavior, perhaps we should allow a forced close
> port to be reopened (by resetting forced_close to FALSE upon
> mm_serial_port_open).

This can depend on how completely the modem simulates an actual modem
and serial port characteristics.  It can also depend on the serial port
TTY attributes that the modem is set up with, and whether it actually
cares about those.  If possible, can you get some info out of the kernel
driver about whether the HUP was locally generated or was generated by
modem control signals?

Dan