Age | Commit message (Collapse) | Author |
|
We have assumed until now that all QCDM ports are based on TTY
drivers, e.g. exposed via USB.
This may no longer be true, so allow creating QCDM ports with
an explicit subsystem instead of defaulting always to TTY.
|
|
Split in its own method the per-subsystem port creation mechanism, and
apply all common AT port settings (e.g. response parser, flags) in a
single place.
|
|
This check is pointless given that we're not implementing API, if
anything it should be an assert. Anyway, just get rid of it, so that
we don't need to update it on every new subsystem we add as supported.
|
|
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
|
|
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
|
|
No longer has to be bound to the USB subsystem.
|
|
By default we provide the implementation for the qmi_wwan driver,
where both control and net ports share the same USB interface.
|
|
Move the logic out of the base modem, and make it applicable only for
QMI modems.
|
|
No longer has to be bound to the USB subsystem.
|
|
By default we provide the implementation for the cdc_mbim driver,
where both control and net ports share the same USB interface.
|
|
Move the logic out of the base modem, and make it applicable only for
MBIM modems.
|
|
The rules to force ignoring certain network ports because the modem is
using some specific drivers should definitely only be applied for the
very known qmi_wwan and cdc_mbim drivers.
If network ports for QMI or MBIM modems are exposed using different
network drivers, don't ignore them.
|
|
There should be no need to do an early check to filter out ports of
the wrong subsystem.
For the user of these methods it is irrelevant if the FALSE is
returned because the port is of the wrong subsystem, or because the
test wasn't added to be probed, or because the test actually failed.
In other words, the ports where the test succeeded will only have
succeeded if they are of the correct subsystem and if the test was
actually executed successfully.
|
|
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
|
|
Do it earlier, before running the parser.
|
|
If multiple kernel device types inherit from MMKernerDevice, and those
are compared against each other, the current logic returns TRUE if the
G_OBJECT_TYPE of one of them is smaller than the other. This function is
checking for equality, so returning FALSE is enough.
|
|
So don't re-process them in the generic modem when grabbing the port.
|
|
If the QMI modem is initialized without a SIM card in it, and it goes
to failed state, allow the modem to be reprobed when a SIM card is
inserted.
|
|
So that the list of ports shown in the Ports DBus property is also
alphabetically sorted by port name, instead of having a mess like
this:
-----------------------------
System | device: qcom-soc
| drivers: bam-dmux
| plugin: qcom-soc
| primary port: rpmsg0
| ports: rmnet5 (net), rmnet_usb0 (unknown), rmnet4 (net),
| rpmsg1 (at), rmnet3 (net), rpmsg0 (qmi), rmnet2 (net), rmnet1 (net),
| rmnet7 (net), rmnet0 (net), rmnet6 (net)
|
|
At the moment, ignored ports show up as (unknown) in the ports list
in mmcli. This makes it look like something went wrong while probing.
Actually ModemManager already tracks unknown and ignored ports separately
(MM_PORT_TYPE_UNKNOWN vs MM_PORT_TYPE_IGNORED) but the API always exposes
them as MM_MODEM_PORT_TYPE_UNKNOWN.
Add MM_MODEM_PORT_TYPE_IGNORED and use this for ignored ports so they
show up as (ignored) instead in mmcli.
|
|
No need to retry checking card status when the application state is
illegal, just treat the SIM card as unusable right away.
https://forum.sierrawireless.com/t/uim-card-application-state-illegal/21842
|
|
When "UIM Switch Slot" returns a NoEffect error it's because we're
already in the desired slot, so just treat it as a successful
operation.
|
|
Running with G_DEBUG=fatal-warnings will end up reporting warning logs
with G_LOG_FLAG_FATAL, which breaks our own logging logic.
|
|
|
|
If the modem goes away (ports removed) during the initialization
phase (e.g. while QMI clients are being allocated), the MMPortQmi
object will be closed and it will lose its internal QmiDevice.
We should therefore consider the lack of QmiDevice a valid usecase in
track_qmi_device_removed() and return a GError when that happens.
#0 0x00007fb544618cc9 in raise () from /lib/libc.so.6
#1 0x00007fb54461bd68 in abort () from /lib/libc.so.6
#2 0x00007fb544e2213d in g_assertion_message () from /usr/lib/libglib-2.0.so.0
#3 0x00007fb544e221ba in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0
#4 0x00000000004be584 in track_qmi_device_removed ()
#5 0x00000000004be5e3 in allocate_next_client ()
#6 0x00000000004be7b1 in qmi_port_allocate_client_ready ()
#7 0x00007fb5453690a3 in g_task_return_now () from /usr/lib/libgio-2.0.so.0
#8 0x00007fb54536967e in g_task_return () from /usr/lib/libgio-2.0.so.0
#9 0x00000000004dd8f8 in allocate_client_ready ()
#10 0x00007fb5453690a3 in g_task_return_now () from /usr/lib/libgio-2.0.so.0
#11 0x00007fb54536967e in g_task_return () from /usr/lib/libgio-2.0.so.0
#12 0x00007fb54591d4de in allocate_cid_ready () from /usr/lib/libqmi-glib.so.5
...
|
|
SIMs can be created with an EID fetched during load_sim_slots
while initializing the modem, if present.
Since load_eid would be implemented with the same mechanism
we avoid using it here (if Get Slot Status fails once, it
probably doesn't make a lot of sense to try it again).
|
|
This provides a new D-Bus property on the Sim object that
exposes the EID of the SIM, if available.
|
|
|
|
All BCD-encoded strings used by MM currently have the low nybble
of each byte come before the high nybble, but some strings (such
as the EID string returned by QMI Get Slot Status) are meant to
be read in order with the high nybble before the low one. As such,
extend mm_bcd_to_string to decode both.
|
|
|
|
The "Serving System" indications reported via QMI when the device is
moving may contain LAC/TAC+CID updates or just CID updates.
E.g. this one has "CID 3GPP" (0x1e):
Mon Aug 3 11:22:42 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 33
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4512 <<<<<< tlv_length = 21 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 14:C2:A8:00 <<<<<< translated = 11059732
And this one has both "CID 3GPP" (0x1e) and "LTE TAC" (0x25):
Mon Aug 3 11:23:05 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 38
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4513 <<<<<< tlv_length = 26 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 32:36:BC:00 <<<<<< translated = 12334642 <<<<<< TLV:
<<<<<< type = "LTE TAC" (0x25) <<<<<< length = 2 <<<
We should therefore allow changes only in the CID, maintaining
whatever LAC/TAC value we had before.
|
|
|
|
According to QC, we should set the IP family in both the
Set IP Family and Start Network messages. After removing this
check the member is never read, only written; this means it's
effectively dead and can be removed.
|
|
Fixes a bug introduced in commit 7e386389, which caused user requested
disable operations to go to step
DISABLING_STEP_FIRST_AFTER_ENABLE_FAILED. For user requested disable,
the first step should be DISABLING_STEP_FIRST.
|
|
Telit FN980 requires more time for becoming responsive to
qmi requests after device appearance.
|
|
Querying facility locks should return a FIXED_DIALING lock if PIN2 lock
is enabled.
|
|
Prior to this CL, failure to get pin status while probing facility locks
would not flag an error. Failure to read a pin lock is a critical error
and we return it to higher layers.
|
|
DMS_UIM messages have been deprecated, and have been replaced by
equivalent UIM messages. Use UIM_GET_CARD_STATUS while querying for facility
locks if dms_uim messages were found to be deprecated.
|
|
The cleanup was missing in one of the steps.
|
|
|
|
On QMI-capable MBIM devices, also setup the SIM hot swap logic using
QMI over MBIM, so that profile changes are detected.
|
|
The SIM hot swap setup is run during initialization and if it succeeds
it must be available throughout the whole execution of this modem
object.
So, do not cleanup the SUBSCRIBER_INFO flag on 3GPP interface disable,
which is completely unrelated to the SIM hot swap setup logic.
|
|
If enabling the subscriber info notifications fails, we should no
longer have the setup for those notifications, so make sure it's
cleaned up on error.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
This reverts commit e91f2ef315526a1a8a1b451acb5a190686b05225.
This was wrongly merged squashing multiple commits together. Reverting
to merge separate commits.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
If the device goes away while we are listing SMS messages, it may
happen that we ask the messaging interface to take a part and the
sms list object has already been disposed. Make sure the part is freed
in that case, so that we avoid memory leaks.
==19138== 6,914 (1,232 direct, 5,682 indirect) bytes in 11 blocks are definitely lost in loss record 5,282 of 5,287
==19138== at 0x483A77F: malloc (vg_replace_malloc.c:307)
==19138== by 0x5023349: g_malloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x50446FF: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x5044D6A: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x2577FC: mm_sms_part_new (mm-sms-part.c:180)
==19138== by 0x2504D0: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:385)
==19138== by 0x21A15C: add_sms_part (mm-broadband-modem-mbim.c:5169)
==19138== by 0x21A31F: sms_read_query_ready (mm-broadband-modem-mbim.c:5215)
==19138== by 0x4E600F3: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4E64638: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4D3870D: transaction_task_complete_and_free (mbim-device.c:236)
==19138== by 0x4D396B9: process_message (mbim-device.c:616)
|
|
|
|
If we had already successfully run the sim hot swap context setup
during the initial initialization, make sure we don't re-run on SIM
PIN unlock, because we may be re-creating signal handlers and such.
|
|
The function shall be needed for profile switch checking.
|