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

[Loic Poulain]

Hi Peter,

On Sat, Oct 10, 2026 at 7:16 PM Peter Hunt <peter.hunt@xxxxxxxxxxxx> wrote:
>
> 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).

I think we can go with option a) for now. The documentation I have
only references virtual RS-232 control signals for DUN, and we can
always revisit this later if additional use cases arise.

>
> 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?

I would also lean toward option a). We may want more fine-grained
locking in the future, particularly given the blocking write path, but
I think the current approach is acceptable for now.

Regards,
Loic