The qcdm wwan device does not cope well with writing single bytes,
while it does not have any issue if longer chunks are written.
Fix qcdm_send accordingly, since it should not hurt the previously
supported devices.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
ME910G1 supports decimal format for 4G bands and has also an empty
tdscdma slot between 4G and 4G extended bands commands/responses.
Change shared code and helpers to deal with these differences.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
The assumption that if a modem supports a given access tech, the band
settings for that specific tech should be always given is wrong for
4g, since the 4g bands can be disabled setting the value to 0 in
multi-tech modems like ME310M1.
For example, a 3g + 4g modem could have a setting in which all
the 4g bands are unset and only 3g bands are there: this scenario is
not supported by the current code, but it's legitimate.
Remove this limitation and adapt the code to support bands setting
for multi-tech modems.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Fix LN920 current bands test configuration by setting
modem_has_hex_format_4g_bands to TRUE.
The current wrong setting does not cause the test failure since the modem
supports also extended settings and function telit_get_ext_4g_mm_bands
considers both standard and extended bands as hex without checking
the flag, since decimal format for extended bands is not supported.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Qualcomm suggests to use mux id values >= 0x81: though this does not
seem a strict mandatory rule, there are scenarios in which the usage of
a specifix mux id is required otherwise various kind of issues could
happen (e.g. call failure, limited throughput...).
A new ID_MM_INITIAL_QMAP_MUX_ID udev tag allows setting the first initial
mux id value to be used when creating the multiplexed data connection.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cleaning up multiple active multiplexed bearers causes an assert in
mm_iface_modem_count_bearers since the max number of active bearers
is not properly determined.
Rework the management of the flags in order to better match their
intents, considering that MULTIPLEXED is a subset of ACTIVE/CONNECTED.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
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>
Kernel driver mhi-net sets a custom MTU for the netdevice: use the
same value when resetting the netdevice to its initial state.
This is important especially when rmnet is used on top of mhi-net,
since rmnet netdevices get their initial MTU from the mhi-net one.
The current requested downlink data aggregation protocol maximum size is
set to 32768, but this is not accordingly set as the MTU of the main
qmi_wwan interface, that is instead set to RMNET_MAX_PACKET_SIZE that is
16384.
So, the modem is able to send QMAP aggregated blocks larger than 16384,
but the driver is not able to properly collect them, since the URB size
is 16384.
It is not simply possible to set qmi_wwan main interface MTU to the
returned dl max aggregated size, since when creating the rmnet netdevice
the rmnet kernel module automatically set the mtu as the size of the
parent netdevice MTU - the qmap header size (4), but this won't work
because the rmnet kernel module does not support MTU > 16384.
As an immediate fix, set the requested dl dap max size to 16384, while
thinking about how to refactor the logic for supporting higher values.
qmi_wwan inbox qmap management is not affected by this issue.
It could happen that when MM starts the aggregation protocol is already
configured on the modem side (e.g. if MM is stopped and restarted): this
prevents the links to be properly configured, resulting in using the qmimux
multiplex implementation even if rmnet is available.
Fix the issue by always performing the first time the links reset procedure,
even if the data format on the modem side is the expected one.
When using QMAPv5 and QMAPv4 the checksum is enabled by default
at the modem level, so it should be also enabled when creating the
rmnet netdevices: add the required flags also when rmnet is used
through qmi_wwan.
When Telit FN990 is integrated through PCIe, but also USB lines are
available, ModemManager will consider the port on the USB composition
as a different modem:
oem@sw-test:~$ mmcli -L
/org/freedesktop/ModemManager1/Modem/1 [telit] FN990A40
/org/freedesktop/ModemManager1/Modem/0 [Telit] FN990A40
oem@sw-test:~$ mmcli -m 0
<snip>
| equipment id: 359172390022295
--------------------------------
System | device: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-5
| drivers: option
| plugin: telit
| primary port: ttyUSB0
| ports: ttyUSB0 (at)
oem@sw-test:~$ mmcli -m 1
<snip>
| equipment id: 359172390022295
-----------------------------------
System | device: /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0
| drivers: mhi-pci-generic
| plugin: telit
| primary port: wwan0mbim0
| ports: wwan0 (net), wwan0at0 (at), wwan0at1 (at),
| wwan0mbim0 (mbim), wwan0nmea0 (ignored), wwan0qcdm0 (ignored)
Ignore composition 0x1075, since it should not be used by ModemManager
and can only show when PCIe is used.
Some firmware versions return an empty string for the revision when
using the device caps MBIM request, so use AT commands as a fallback
in case this happens.
Some modems (e.g. Telit FN990) reports 5G capabilities in CustomDataClass
field of device-caps cid: take this into account when building the
modes according to the data caps.
The new QCDM probing mechanism does not probe and grab QCDM ports
if the plugin is not allowed, so QCDM ports currently ignored in
compositions can be safely marked as ID_MM_PORT_TYPE_QCDM.
The new QCDM port probing and grabbing mechanism implements a new
property for detecting the plugins which require the QCDM port to
be probed and grabbed.
Add the property to the affected plugins.
The QCDM/DIAG port is usually nowadays exclusively used by applications
gathering traces from the modem, so avoid port probing and grabbing
when plugins set the property MM_PLUGIN_ALLOWED_QCDM.
A new property MM_PLUGIN_REQUIRED_QCDM is created for those plugins
requiring the QCDM port for properly using a modem.
Fix the following segmentation fault:
ModemManager[128007]: mm_port_peek_kernel_device: assertion 'MM_IS_PORT (self)' failed
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x00005555556c6e3e in mm_kernel_device_get_global_property
(self=0x0, property=0x7ffff5947480 "ID_MM_TELIT_BND_ALTERNATE")
at kerneldevice/mm-kernel-device.c:309
Reported by Carlo Lobrano <c.lobrano@gmail.com>
Add a polling mechanism for port responsiveness, since some modem
families require some time before being usable after the serial
ports have been exposed by the kernel.
While at this change also the previous generic reference to ME910
in order to differentiate between ME910C1 (based on MDM9206) and
MEx10G1 (based on MDM9205).
Telit LTE modems use #PSNT: 4 for LTE access technology,
and #PSNT: 5 for unknown access technology, while HSDPA
modems use #PSNT: 4 for unknown access technology.
This patch fixes those #PSNT values interpretation according
to the modem capabilities.
Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
Original patch by Aleksander Morgado.
Telit LE922A does not like the legacy way for checking pin status, but
instead of returning QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND, it returns
QMI_PROTOCOL_ERROR_NOT_SUPPORTED, making the modem not to be fully
initialized.
This patch adds QMI_PROTOCOL_ERROR_NOT_SUPPORTED as another error for
which the new pin checking status way is tried.
GE910 is a 2g only modem and when queried for bands it returns
only a 2g set of bands:
--> 'AT#BND=?<CR>'
<-- '<CR><LF>#BND: (0-3)<CR><LF><CR><LF>OK<CR><LF>'
Current regex fails, since it considers the 3g bands block mandatory.
A similar problem happens for current bands.
This patch modifies the regular expressions for properly
supporting GE910 and updates tests.
GE910 family supports #PORTCFG layouts different than HE910
family ones.
This patch properly tags GE910 ports according to Telit document
"GE910 Family Ports Arrangements, 1vv0301049"
This patch adds another Infineon flashloader device 0x8087/0x0801
to the blacklist
Reference to the kernel commit:
github.com/torvalds/linux/commit/f190fd92458da3e869b4e2c6289e2c617490ae53
Adding dynamic port identification for Telit modems that support AT#PORTCFG
command. Port configurations for HE910/UE910/UL865 taken from document
"HE910/UE910/UL865 Families Ports Arrangements User Guide"
Daniele Palmas