[RFC] What to do by default with DIAG/QCDM ports

[Aleksander Morgado]

Hey,

> > 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.
>
> Sounds fine to me. It's probably "easy" to figure out which
> devices/drivers can benefit from QCDM, except that (unfortunately) many
> of those will be driven by 'option'.
>
> Is it possible to only probe QCDM for certain modems, and only if
> AT+GCAP returns 3GPP2 responses?
>

Ah! that is a very good idea. I think we could add that logic in the
probing sequence somehow, so that we run QCDM probing on all TTYs that
were not probed as being AT, and only if AT+GCAP returns 3GPP2
specific responses in the AT commands.

> >  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.
>
> I'm less sure about this. But most cases I can think of that need this
> are old 2-port devices, one AT and one QCDM, so if we find an AT port,
> the other is most likely QCDM.
>

We could still probe the QCDM-flagged ports if there are AT ports
returning 3GPP2 responses as in the previous comment, that logic is a
good one I think to cover this case as well.

> >  3) Avoid using the QCDM ports during runtime in all 3GPP capable
> > modules, and only use them in 3GPP2-only modules.
>
> Probably OK. Some old Qualcomm devices (mdm6x range? and some old 2G
> phones) IIRC only had two ports, AT+PPP and QCDM and you needed DM to
> get system state and signal status while connected. But it's probably
> safe to assume that anything UMTS or later doesn't need QCDM, and
> special-case those that do.
>

Yes, we can add that.

> > 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?
>
> We can start to build that list, at least?
>

Do you recall any of the CDMA modems in your collection that we could
add to the list right away?

-- 
Aleksander
https://aleksander.es