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>
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>
Logger id (the one generated from build_id interface method and owner_id
property) is generated and cached the first time it is required, further
uses just return the cached value.
Add a cache reset method so if the interface implementer knows that its
logger id could have changed it could force its re-generation.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Otherwise we'll get a NULL pointer dereference segfault in mm_auth when
sending SIM PIN.
Looks like MMBaseSim was accidentally missed during the conversion done
by the commit in the Fixes tag below.
Fixes: ef5cee3ab5 ("auth-provider: move auth provider logic into each class")
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Since commit 63dd4ad2 it is possible that the GPS interface is in use at
the time of modem reinitialization so it should not be stopped in such
case.
Otherwise "mmcli --location-status" will still say that GPS is enabled but
no GPS traces are going to be coming.
The modem location interface loads modem location capabilities only during
the very first initialization of this interface.
On each later reinitialization it skips loading these capabilities from
modem, however it still goes through the whole interface initialization
state machine.
This state machine uses its own "ctx->capabilities" field for temporary
capabilities storage, which is set to MM_MODEM_LOCATION_SOURCE_NONE at the
start of the initialization process.
However, if we aren't actually loading modem location capabilities because
we're only reinitializing the interface we still need to set this
"ctx->capabilities" field to the existing (previously loaded) modem
location capabilities.
Otherwise the next interface initialization step (validation) will
permanently disable the whole location interface.
Maciej S. Szmigiero