Re: [PATCH net-next v8 2/2] net: wwan: mhi_wwan_ctrl: drive DTR/RTS via the IP_CTRL channel

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

Thanks for the review.

[High] refill work racing mhi_unprepare_from_transfer() in remove():
agreed, and Loic raised the same point. In v9 the DL sink buffer is
only requeued from the refill work (the DL callback just schedules it),
and remove() calls disable_delayed_work_sync() before
mhi_unprepare_from_transfer(), the same order mhi_wwan_ctrl_stop()
uses for the data ports.

[Medium] a DL callback still running after remove() frees dtr: v9's
change stops a late callback from re-arming the work, but if a
callback could still be running after mhi_unprepare_from_transfer()
returns, it would also touch freed memory. That is the same guarantee
the existing data-port code in this driver relies on, as
mhi_wwan_ctrl_remove() frees mhiwwan after the channel is unprepared
while mhi_dl_xfer_cb() dereferences it. So if the window you describe
can happen, I think it belongs in the MHI core rather than in each
client driver, and I've left this driver consistent with the rest.

[Medium] DTR/RTS updates that don't reach the modem are not retried
or replayed: this is intended and described in the commit message.
Each TIOCMSET/TIOCMBIS/TIOCMBIC resends the full state, open and close
send it again, and cdc-acm treats a failed control request the same
way. The replay case needs the IP_CTRL device to be unbound and rebound
by hand while an AT port is open.

v9 follows with these changes.