The device would eventually be automatically probed. Add hints anyway,
as not to waste time with the generic probe.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
MV31 MBIM modem firmware revisions are not matched with carrier configs.
Different VoLTE profiles might be selected by the user causing
the carrier config revision to change.
Since fwupd uses this string for firmware updates, it gets confused and
thinks the user has an update available.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reading the hardware revision via the mbim interface returns an incorrect
hardware revision string. The output is always set to
'h/w revision: Thales Snapdragon X55'
Hardware | manufacturer: Cinterion
...
| h/w revision: Thales Snapdragon X55
This is an incorrect value returned by the MBIM interface. The MV31 and MV32
does have a dedicated AT Command to get the correct hardware revision
via 'AT+SKUID'. If the hardware revision is read via the AT command, the
output looks as follows.
Hardware | manufacturer: Cinterion
...
| h/w revision: V065
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reading the revsion via the mbim interface returns an incorrect firmware
revsion string. This contains a '\n' character so that the revision looks
like this in 'mmcli'.
Hardware | manufacturer: Cinterion
| model: Cinterion PID 0x00F1 USB Mobile Broadband
| firmware revision: FDE.F0.3.0.1.1.DT.005
| 062
| carrier config: DT
The correct string without '\n' is returned via the AT interface. To fix
the error, the 'mbim' revision interface is overwritten with an AT call
if a MV31 or a MV32 is detected. So we get the correct output via 'mmcli'.
Hardware | manufacturer: Cinterion
| model: Cinterion PID 0x00F1 USB Mobile Broadband
| firmware revision: FDE.F0.3.0.1.1.DT.005.062
| carrier config: DT
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Some modems (at least ELS62-E) doesn't support TDD LTE bands and their SCFG
responses doesn't contain LTE-TDD bands.
Signed-off-by: Kirill Buksha <kirbuk200@gmail.com>
Treat the following URCs as indications of possible SIM hot swap
events:
+SIM: Inserted
+SIM: Removed
+SIM DROP
Any time any of these is received, a SIM hot swap event is reported,
and the logic can then determine what to do. These should lead to
doing nothing if they happen as part of a controlled SIM slot switch.
Signed-off-by: Aleksander Morgado <aleksandermj@google.com>
It seems that the very first XMM7360 RPC init command often times out after
resuming the laptop from s2idle for unknown reasons.
This makes the modem unusable in such situation until the next sleep/resume
cycle.
Re-trying this RPC command allows the modem to initialize normally.
It's possible that this is a kernel iosm driver or modem firmware issue
but considering that the kernel driver seems orphaned by Intel and one
can't really expect much firmware support for this modem either let's do
the easiest thing and simply allow retrying (once) the very first RPC init
command if it fails or times out.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
With the recent addition of serial port scheduler it often happens that
NMEA traces are mistaken for command responses at init time if GPS was left
enabled in the modem.
For this reason, the proper NMEA packet parser needs to be enabled early
at modem init before the code ensures that GPS is stopped (if it is not
supposed to be running of course).
Since this modem disables GPS asynchronously with processing of the
+XLSRSTOP AT command the full GPS stop machinery has be used to reliably
achieve that GPS engine stop.
It's also important to flush the existing serial port data after attaching
the NMEA packet parser but before issuing that stop AT command, otherwise
command processor for the stop command can also be confused by the existing
queued data.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
XMM7360 modem NMEA trace packets are wrapped to look like AT command
responses (with "<CR><LF><CR><LF>OK<CR><LF>" at the end).
This wrapping causes problems if a genuine AT command was just sent and
ModemManager is expecting a similarly formatted response to it.
In such case the NMEA trace packet is taken as the response to the AT
command, which usually causes the command to fail due to response parsing
failure.
Fix this by implementing a custom NMEA trace packets parser for these
modems.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
With serial port interlocking just queuing serial port data does not mean
it will be immediately sent - the other serial port could be still busy.
For debugging serial port issues it is often necessary to see the exact
moment the data was sent or received.
Implement debug_log method for MMPortSerialXmmrpcXmm7360 and log raw serial
port data there (just as MMPortSerialAt does) instead of doing this in the
command queuing function.
The debug_log method is called by MMPortSerial base when the data is about
to be actually sent to the serial port.
Additionally, log command response body where it is actually returned to
higher layers rather than in the unsolicited response handler.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
We need to keep GPS port open if would not be kept open otherwise (like
it is the case with a locked/non-enabled modem).
Otherwise:
* While GPS can be enabled in that modem state the traces don't reach MM
API consumers since nothing is servicing the serial port.
* Once modem actually gets enabled the queued GPS output in the modem
serial port floods the main port and often confuses the init sequence.
We also have to make sure that we don't stop GPS during the init sequence
if it is supposed to be running, otherwise there will be the same
issue as commit d3a2aebf16 ("mbm: don't stop GPS interface on
reinitialization if it should be running") fixed for mbm.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Seems to work just fine once the port interlocking is being done
and some other fixes are made in the next commit.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
We have to avoid sending RPC and AT commands at the same time (even thought
they are sent via different serial ports) since apparently this modems does
not like it.
It also looks like this modem does not like to receive a RPC command soon
after an AT one, since such RPC commands sometimes fail to generate any
response.
Prevent this problem by delaying a RPC command if there was an AT command
completed recently.
The sufficient time gap was determined experimentally, but 300 ms seems to
be enough.
RPC commands are relatively rare so this should not be a performance issue.
Otherwise we often never get any response to RPC calls if AT command
happens to be sent at the same time.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Commit ec5104c9a8 ("Move log parent and connection property binding
to helper") made it obligatory for MM_TYPE_BASE_BEARER and MM_TYPE_BASE_SIM
derived classes to specify MM_BIND_TO property, but recently merged XMM7360
support wasn't converted before being merged.
This caused XMM7360 to fail to set-up SIM D-Bus object and mmcli to throw
assertions when trying to access that non-existing SIM object.
Add the missing XMM7360 MM_BIND_TO properties.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
The arguments are `gsize` and otherwise emit warnings on e.g. i386
Fixes 4cae04064 ("intel: implement support for RPC-powered xmm7360")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
T99W696 is the first Foxconn PCIE modem whick uses Qualcomm's VID/
PID. Driver ref: https://lore.kernel.org/mhi/20250528092232.16111-1-slark_xiao@163.com
This changes include 2 parts:
i: Add device for foxconn plugin
ii: Show SSVID/SSPID for parameter "--firmware-status". This helps
the fwupd get the right firmware upgrade method.
Signed-off-by: Slark Xiao <slark_xiao@163.com>
Instead of hard-coding a 500ms DTMF tone duration, let applications
use a specific duration at call setup time.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Some older MTK-based phones (Tecno T528 NEW) reply to +CPIN with
an error but are (obviously) unlocked, otherwise they wouldn't
be able to boot up to the point of talking to a computer. Since
they are actually unlocked they will happily give out the IMSI
even if +CPIN errors.
To work around the +CPIN issue treat the device as unlocked if we
can successfully read the IMSI.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/980
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Mainly because we need somewhere to stash the call end regex, and
it's silly to have a 3rd instance of that in MMPortSerialAt when
we already have one in the serial parsers that MMPortSerialAt
relies on pretty heavily.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
AT docs for many (most?) Quectel devices state that QPOWD=1 receives
the OK response very quickly but the caller must wait for the
POWERED DOWN URC to avoid data loss. Do that.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
For modems that need more time to respond to AT port probes (like some Telit devices,
and Cinterion-based Telit MV31/MV32) allow a custom number of AT probe tries on a
per-port basis for generic probing, or plugins that opt into this functionality.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Allows setting the renamed `ID_MM_QUALCOMM_FIREHOSE` and
`ID_MM_QUALCOMM_SAHARA` environment variables for all devices.
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
Vanillan Wang
Lubomir Rintel
Florian Eckert
Kirill Buksha
Aleksander Morgado
Maciej S. Szmigiero
Dan Williams
Guido Günther
Slark Xiao
Daniele Palmas
Thomas Vogt
Lukas Voegl
Michał Sułek
Aleksander Morgado
Sushrut Shree Trivedi