[RFC] What to do by default with DIAG/QCDM ports
Aleksander Morgado
aleksander at aleksander.es
Mon Dec 14 08:50:43 UTC 2020
Hey Dan and all,
The DIAG/QCDM ports were extremely important in some old CDMA modems
that required them for control instead (or in addition to) the AT
ports, at least for several purposes like gathering access tech info
and such. Due to that, MM has been attempting QCDM probing by default
in all TTYs without explicit hints, and also obviously in the ports
flagged as QCDM.
In the past years, this need of the QCDM port during runtime has been,
I believe, non-existent; at least for all new modules. There has been
a real usecase, though, that our automatic port probing has been
interfering with, which is the ability to gather QXDM logs by the
users when the vendor requires them to do so in order to debug
problems. These logs are gathered via QXDM, and ModemManager touching
the port has been interfering with that operation in a bad way,
forcing all users to explicitly ID_MM_PORT_IGNORE those ports on top
of our default rules.
My suggestion, let me know what you all think, would be to:
1) No longer automatically probe for QCDM capabilities in the TTY
ports that are not flagged with port type hints.
2) If the TTY is flagged with QCDM port type hint, also avoid the
explicit probing, just assume it is capable of doing QCDM/DIAG.
3) Avoid using the QCDM ports during runtime in all 3GPP capable
modules, and only use them in 3GPP2-only modules.
I'm sure we would be losing support for some old modules if we do that
above, as we don't have explicit port type hints for all modules, so
not sure what you all think.
Ideally, we would have a list of known CDMA modules that do require
the QCDM port for sure (i.e. that require QCDM for operations that are
not possible with AT or QMI). Maybe it's not that difficult to build
that list?
--
Aleksander
https://aleksander.es
More information about the ModemManager-devel
mailing list