On Mon, May 22, 2017 at 6:09 PM, Dan Williams <d...@redhat.com> 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). -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
