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>
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>
Dan Williams
Florian Eckert
Andrey Skvortsov
Daniele Palmas
Vanillan Wang
Rukun Mao
Kirill Buksha
Aleksander Morgado
Aleksander Morgado
biemster
Guido Günther
Maciej S. Szmigiero