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

[Daniele Palmas]

Hi Peter and Loic,

Il giorno lun 12 ott 2026 alle ore 14:15 Loic Poulain
<loic.poulain@xxxxxxxxxxxxxxxx> ha scritto:
>
> 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.
>

Agree, I don't think control signals are used for diag.

Regards,
Daniele

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