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>
Otherwise only Setup() method for suboptimal polling is available to
non-privileged users.
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Track when the timeout was started, so that if it needs to be increased
we can calculate how long the new timeout should be. Then cancel the
original timeout and start a new one with.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Add EUTRAN 106 band with an offset of 1000 since the current numbering
scheme overlaps with MM_MODEM_BAND_CDMA_*.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
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>
If there is an ongoing SIM slot switch, we must ignore all SIM hotswap
related events happening during the process. The flag that is set in
the Modem interface private info to track this is never reset back to
FALSE on a successful SIM slot switch, it will be set for as long as
the modem object exists.
After the successful SIM slot switch, a new modem reprobe will be
requested, which leads to the old modem object to be disposed (the one
that had the flag set) and a new modem object created.
The logic that already existed in the MBIM modem object is now
generalized in the Modem interface itself so that SIM events reported
via other protocols are also properly ignored.
Signed-off-by: Aleksander Morgado <aleksandermj@google.com>
This introduces the "terse" mode during quick suspend/resume, right now
it is used by 3GPP interface to disable unsolicited events, but in
future it can be used by other interfaces as well.
This prevents device to wake-up from suspend for each unsolicited while
still allowing to wake up on calls or SMS messages.
Signed-off-by: biemster <biemster@gmail.com>
Signed-off-by: Bhushan Shah <bshah@kde.org>
In preparation for a "terse" mode, but also because "shutdown" was
kind of weird since we're not always shutting the modem down; sometimes
we're just putting it in low-power mode.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
We currently overwrite the value without freeing it.
Fixes: d8135be6e ("modem-helpers: Add helpers to parse channel lists")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
`g_ptr_array_new()` creates an array without a free func,
this means we'd leak the strings when the reference count
drops to 0.
Fixes: 56fe8e7d3 ("modem-helpers: add utility function to split DTMF runs")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
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>
Add a serial port flush operation which can be used to discard either
serial port data received but not read, or serial port written but not
transmitted, or both types of 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>
Dan Williams
Lukas Voegl
Florian Eckert
Andrey Skvortsov
Daniele Palmas
Vanillan Wang
Rukun Mao
Kirill Buksha
Aleksander Morgado
Aleksander Morgado
biemster
Guido Günther
Maciej S. Szmigiero