Re: [PATCH net-next v8 1/2] net: wwan: core: propagate modem control signals to port drivers

[Peter Hunt <peter.hunt@opengear.com>]

Hi Loic,

A follow-up to my reply, as I overstated one point and would rather ask
than argue on both. (Adding Daniele, as the first question touches his
recent QCDM ioctl work.)

On the AT-only check: I said QCDM has no DTR semantics, but I don't
actually know that. I've only verified DTR/RTS on the AT (DUN) port of a
Sierra EM9291. I don't know whether the DIAG channel behind QCDM ports
honours DTR on these modems, or whether libqcdm relies on it now that
QCDM ports have the TIOCM ioctls. So I see two options:

  a) Keep it AT-only in all four places (open, close, removal, ioctl).
  b) Call ->dtr_rts for any port with the TIOCM ioctls (AT and QCDM)
     whenever the driver implements it, again in all four places, and
     leave it to the driver to ignore ports where it doesn't apply.

Which would you prefer? If you or Daniele know that QCDM/DIAG ports
care about DTR, that would settle it for b).

On the locking: I agree the data_lock/ops_lock split is awkward, and
it's this series that made the two locks interact. Most of the races
found in earlier versions came from it. My only concern is the blocking
write case I mentioned, so the options as I see them are:

  a) Use only ops_lock, with the whole ioctl handler under a guard and
     mutex_lock_interruptible() so a waiting ioctl can be interrupted,
     accepting the wait behind a blocking write on rpmsg ports.
  b) Keep data_lock for the termios/TIOCM state and take ops_lock,
     interruptibly, only around the ->dtr_rts call. v9 already limits
     that to when DTR or RTS actually changes.

I'm happy to do either in v9, which do you prefer?

Thanks,
Peter