Hi Denis, Piotr, I have just submitted a patch. Piotr, you probably should add your sign-off on it, as about half of it came directly from you.
I am still a little bit confused about ofono_gprs_cid_activated(). As far as I can see only atmodem calls it. No other driver does that. The flow of user calling create-internet-context and activate-context seems to work fine with my patch. I am not sure if a context is automatically created. I can see that the sim card has a few profiles, and the user can select which APN to use, start/stop ip network, etc. Let me know if what I coded is ok. I am happy to make changes as required. Thanks. Lukasz On 20/03/17 23:39, Denis Kenzior wrote: > 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
