We don't support SIM/RUIM on CDMA devices (yet), so for now it makes
no sense to run the after-sim-unlock step on CDMA-only devices where
a SIM won't be present.
Unfortunately we don't know at this point whether there is a SIM
or not, so if the modem is a multi-mode device (implying it has a SIM
slot) and its plugin implements the modem_after_sim_unlock() hook,
the hook will still be executed and might cause an unecessary delay
when a SIM is not inserted.
Use a static GString which will resize itself if the log message
is bigger than the current string size, but will also ensure we
don't do a ton of memory reallocation on every log message.
Previously all log messages were trucated at 512 bytes due to the
log buffer char array being 512 bytes long.
The specific case:
* Modem exposes cdc-wdm port, Generic plugin probes it successfully as QMI.
* Modem exposes new ports, including the wwan one. All ttys fail probing
because they're neither AT nor QCDM (CnS in this case).
* The wwan port ends up without a port being suggested and is not grabbed.
The root cause of this is that we do not propagate the suggested plugin to newly
added ports when it's the Generic one. If it wasn't the Generic one, the newly
added ports would start with the suggested one for probing.
Now, handle this by looking for the device-specified plugin when the port
probing ends without a specific port given. If there is such a device-specified
plugin accept the port, and otherwise, reject it.
Many multi-mode Qualcomm devices report all available modes in their
AT+GCAP response (for example, CDMA/EVDO and GSM/UMTS) but they cannot
actually function in all these modes at the same time. The modem's
actual current capabilities are expressed by the QCDM NV ModePref
item, which is not reflected in the AT+GCAP response.
Reading the current capabilities from the NV ModePref item ensures
that ModemManager does not create interfaces for the modem which
the modem cannot actually implement.
Because the generic modem plugin does not implement the Modem
Capabilities hook (because there is no standard way to determine
what access technologies a modem supports), the Current Capabilities
are copied to the Modem Capabilities. For devices that support
QCDM this means that Modem Capabilies which used to be created from
the GCAP response and thus would contain all available capabilities
now contain only current capabilities. This isn't a problem though
since there was no way to switch the devices to use any of their
other capabilities, becuase there aren't any standard commands for
it. Plugins that know how to switch their modem's capabilities
should (and they already do) override load_current_capabilities
and load_modem_capabilities to get the correct information.
Sync with libmbim commit:
commit b73673bf30a82e95819deb17296c9234399f0795
Author: Aleksander Morgado <aleksander@lanedo.com>
Date: Thu Apr 11 20:07:12 2013 +0200
mbim-codegen: properly define the 4 types of messages that we may have
There are many more places where we reload remaining attempts, not just after
querying initial lock status. So re-query to get the most up to date info.
