On 22/05/17 19:08, Aleksander Morgado wrote: >>> And now that I see this... >>> * Shouldn't we enable +CIEV only for "signal" (that's the only thing >>> we end up parsing in the generic +CIEV parser)? >>> * Shouldn't we move this setting to the generic broadband modem >>> implementation? >> All three of these (signal, service, roam) are pretty standard. Why >> not move all of them to the generic implementation and make use of them >> if we can? > In the generic implementation we already have those 3 being > "supported" more or less. We do run +CIND=? and get the indices for > each item, but if a +CIEV URC arrives with any of them set, we only > really parse and use the "signal". We don't parse and use service or > roam because we are already doing processing the same info via > +CREG/+CGREG/+CEREG indications. Question now being, should we parse > and use service/roam values reported via +CIEV URCs? Is there any info > returned in that way that we wouldn't get from +CREG/+CGREG/+CEREG > indications? > > The change in the Telit plugin also seems to explicitly enable those > indications; while the generic plugin assumes they're enabled. Maybe > we shouldn't assume anything and we should directly request them. But > we wouldn't have a fixed command like in the Telit plugin, instead we > would make use of the indices of each item to construct the correct > command (i.e. without assuming in which index each item is).
Regarding this, I will suggest a separate patch to enable the +CIEV URCs directly in the generic modem, instead of doing it in the Telit plugin. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
