Hi Lukasz,
Strictly speaking this statement is correct. In LTE there's really no concept
of 'attached'. We're attached by the virtue of getting onto the LTE network
(the default bearer is always available). So there should be no need to
explicitly issue a set_attached method.
The current qmimodem code, calls
ofono_gprs_status_notify(NETWORK_REGISTRATION_STATUS_REGISTERED) when it receives a
notification from the modem that it is fully connected. Is that the correct path to make
the gprs context marked as "attached"?
If that does not happen, all the dbus context APIs just return an error, and as
a result, e.g. connman does not enable the cellular service.
So as it is today, oFono for LTE expects the following:
ofono_gprs_status_notify(with registered / roaming)
and ofono_gprs_cid_activated() for the default bearer.
The gprs-context driver must then implement read_settings method. LTE
is weird since the contexts can be network activated. The default
bearer is 'activated' by the modem firmware itself by virtue of
obtaining the LTE network registration. The logic is quite different
compared to 2G/3G.
If you know your AT commands, see how the ubloxmodem driver does this.
Pay attention to drivers/atmodem/gprs.c cgev_notify() and
drivers/ubloxmodem/gprs-context.c.
We also now have an lte atom. See doc/lte-api.txt for details.
If the above isn't possible for QMI, then we might need to tweak the
core logic (e.g. src/gprs.c) accordingly.
Please note that qmimodem driver was developed when we didn't have lte
support, so the logic in there is probably incorrect / inadequate.
I can add a change to qmimodem, which will explicitly ask the modem firmware if
it is connected, from qmi_gprs_probe() rather than waiting on a state change
notification, which never arrives.
Does that make sense?
How do you usually test such changes for regressions? I do not have any other
QMI modems, to verify if I have broken anything in them or not. I think the
change should be safe, but I cannot be 100% certain.
We try to catch most regressions during the patch review process. In
the past we had some QA resources performing manual tests, but these
resources are no longer available. Easiest might be to order a few qmi
modems and check if your patches break them :)
Regards,
-Denis
_______________________________________________
ofono mailing list
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono
