GCC 10 warns about this implicit conversion:
drivers/huaweimodem/radio-settings.c: In function ‘band_gsm_from_huawei’:
drivers/huaweimodem/radio-settings.c:107:10: error: implicit conversion from ‘enum ofono_radio_band_umts’ to ‘enum ofono_radio_band_gsm’ [-Werror=enum-conversion]
107 | return OFONO_RADIO_BAND_UMTS_ANY;
Member from the incorrect enum was returned, both had the value 0, so
the code would still work.
Commit 6c574ee24a ("huawei: the AT^SYSCFGEX
command supports additional modes") has a mistake for acqorder "0201". It
should be UMTS and GSM preferred.
- LTE and UMTS preferred (acqorder = 0302);
AT^SYSCFGEX="0302",40000000,2,4,40000000
- UMTS and GSM preferred (acqorder = 0201);
AT^SYSCFGEX="0201",40000000,2,4,40000000
For AT^SYSCFG, the modes are not available.
AT^SYSCFGEX must be used on LTE Huawei modems to enable LTE support.
But some modems (or firmwares?) do not support this command and AT^SYSCFG
must be used to get/set radio settings.
This has been introduced in commit:
22adf6402c
There is a bug in this commit and AT^SYSCFGEX commands are used even on
modems not supporting it.
There are a large number of files in the tree that define _GNU_SOURCE
despite not actually using features hidden behind this flag. This patch
removes all these definitions in one fell swoop...
The driver vtables are read-only structures. This patch declares them as
'const' allowing the compiler to (optionally) put them in the RELRO
section. RELRO pages may be marked as read-only by the linker after
the relocations have been done ensuring that they aren't inadvertently
or maliciously altered at runtime.
Huawei LTE modems use AT^SYSCFGEX and AT^SYSINFOEX instead of
AT^SYSCFG and AT^SYSINFO.
If we want to be able to attach on LTE with this modem, we must use
AT^SYSCFGEX to configure rat mode and band. Using AT^SYSCFG, mode any
means UMTS or GSM.
strtol clamps returned value between INT_MIN and INT_MAX, causing
invalid value (255.255.255.127) being reported for any address
if last octet > 127 when sizeof(long) == 4.
Voice output serial port is enabled on some Huawei models (e.g. E169)
without problems, but for example on E173u-2 it is never enabled
during an incoming call. There might also be other Huawei models
having the same issue.
I traced the issue down to "^DDSETEX" AT command, which is used
to notify the device to start streaming audio. It seems that Ofono
sends this command too early on incoming calls. The command should
always be sent *after* the dial "D" or answer "A" command. The patch
fixes this behavior and afterwards voice will also work on E173u-2.
The Huawei devices support a special 8-bit PDU mode for USSD that is
by default selected (AT^USSDMODE=1). It avoids the complicated logic
for character set selection and conversion.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>