Re: [RFC] What to do by default with DIAG/QCDM ports
On Mon, 2020-12-14 at 09:50 +0100, Aleksander Morgado wrote: > 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. 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? > 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. > 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. > 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? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Unknown behaviour when signal quality is poor
Hello ! First of all, thanks in advance for your time and dedication. I am developing an application making use of libmm-glib high level API and running under *ModemManager version 1.10.6*. I am currently experiencing some trouble and I would like to know if the behaviour of the Modem + ModemManager system is the expected one or there is some kind of malfunction somewhere. The problem is that we are experiencing some signal problems around an specific area (particularly, every time that a bus passes by an area where the signal strength is poor). I *attach *the *ModemManager debug logs* of the outward and return journey only when the bus is passing by this area. Regarding this, we have the following doubts: - Is the behaviour of the ModemManager the expected one ? Our application queries the ModemManager to scan for devices periodically, can this cause an unexpected behaviour ? - We are using a "global" M2M card which should be able to use different network operators. Is the ModemManager able to switch between operators in order to achieve better signal strengths ? If this is not the case, in order to achieve this, how would we need to proceed? Once again,thank you very much. Kind regards, Alejandro Vega ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
[RFC] What to do by default with DIAG/QCDM ports
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 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
