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