Hi Reinhard,
So this looks good to me. Since Reinhard has provided invaluable insight >> into how QMI works in the past and seems to have 'insider'
knowledge, maybe
we can get him to also comment on whether the approach is correct (e.g. whether querying / setting the default profile is equivalent to setting the default LTE attach parameters) or if there's another QMI command that should be used.Hi Denis, unfortunately the assumption that the profile number returned from WDSGetDefaultProfileNumber is used for handling the default LTE attach parameters does not hold in all cases: 1. Huawei ME909u devices are known to use <cid>/profile number 16 for LTE attach although WDSGetDefaultProfileNumber returns 1. 2. Some devices like SIMCom SIM7230E will still use their "default default profile number" even if WDSSetDefaultProfileNumber has been used to set it to different value (which is also reported as changed by WDSGetDefaultProfileNumber). Some older devices like Sierra Wireless MC77xx do not implement WDSGetLTEAttachParameters.
Okay, so it sounds like we have some vendor quirks to take care of.
Since I only have to support a fixed number of QMI devices I still use AT commands and a fixed <cid> (16 for the ME909u, 1 otherwise) to handle the default LTE attach parameters. An approach like this may not be suitable for a general framework like Ofono.
In theory there's nothing preventing us from using AT commands to implement the lte atom for QMI based devices. You can mix and match atom drivers from different driver trees fairly easily.
Another alternative is to introduce vendor quirks for QMI, similar to how we use enumerations defined in drivers/atmodem/vendor.h.
Regards, -Denis _______________________________________________ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
