Re: [PATCH net-next v5 0/3] net: wwan: support DTR/RTS on AT ports via MHI IP_CTRL

On 8/20/26 12:49 AM, Peter Hunt wrote:
> Qualcomm/Sierra SDX55/SDX65 modems (e.g. EM9291) withhold unsolicited AT
> result codes until the host asserts DTR.  The in-tree mhi_wwan_ctrl driver
> exposed AT ports but never signalled DTR, so URCs never reached userspace.
> 
> Patch 1 extends the wwan core with an optional ->dtr_rts(port, mdmbits) port
> op.  The TIOCM bitmask state is tracked entirely in the wwan core; drivers
> receive the full bitmask so they can drive DTR and RTS independently.  The
> core raises DTR/RTS on first open of any AT port whose driver implements
> ->dtr_rts and drops them on last close, mirroring TTY semantics.  In the
> ioctl path mdmbits is re-read under data_lock inside ops_lock so the value
> passed always reflects the committed state and concurrent ioctls are
> correctly ordered.  wwan_remove_port() also de-asserts on hot-unplug.
> 
> Patch 2 enables the IP_CTRL MHI channel in the Sierra PCI table so that
> the IP_CTRL driver (patch 3) is actually bound on those controllers.
> 
> Patch 3 adds a second mhi_driver that binds the IP_CTRL channel and
> registers a ->dtr_rts op so that the wwan core's open/close DTR raise/drop
> and userspace TIOCMSET calls both reach the modem.  A single recycled sink
> buffer keeps the IP_CTRL DL ring live so the modem's transmit path does not
> stall.  The existing AT/QMI/MBIM data path is untouched.
## Form letter - net-next-closed

We have already submitted our pull request with net-next material for v7.3,
and therefore net-next is closed for new drivers, features, code refactoring
and optimizations. We are currently accepting bug fixes only.

Please repost when net-next reopens after Aug 31st.

RFC patches sent for review only are obviously welcome at any time.

See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle