Initial signal quality query on MBIM modems

[Aleksander Morgado]

>> > ModemManager currently relies on unsolicited MBIM_CID_SIGNAL_STATE
>> > notification to obtain signal quality updates, and it doesn't query
>> > the
>> > initial signal quality. I've observed that some MBIM modems issue a
>> > MBIM_CID_SIGNAL_STATE
>> > notification only when there is a notable change in RSSI. The signal
>> > quality may remain at 0 for quite some time. It's more noticeable
>> > when
>> > simply restarting ModemManager after the modem has been initialized
>> > and
>> > enabled once.
>> >
>> > We could simply enable periodic signal quality polling on an MBIM
>> > modem,
>> > but that's less ideal as it may unnecessarily wake the modem up from
>> > USB
>> > selective suspend (unless we use a much longer polling period).
>> >
>> > I'm thinking about letting ModemManager issue an initial
>> > MBIM_CID_SIGNAL_STATE query when it enables MBIM_CID_SIGNAL_STATE
>> > notification.  Does that sound reasonable to you. If so, I'll submit
>> > a
>> > patch.
>>
>> Sounds OK to me.
>
>
> On a related question, it seems like QMI uses both periodic polling and
> unsolicited indication for signal strength updates. Is that intentional?
> If we decide that it's best to handle signal updates over unsolicited
> notifications for MBIM and QMI modems, perhaps we could bake the logic in
> MMIfaceModem instead.  Currently, MMIfaceModem skips periodic updates if the
> load_signal_quality function pointer is NULL or if load_signal_quality
> returns UNSUPPORTED. Neither addresses the case where we want to call
> load_signal_quality to load the initial signal quality but skip further
> periodic polling.  I guess we could use a
> MM_IFACE_MODEM_PERIODIC_SIGNAL_UPDATES_DESIRED property to indicate such an
> intention?
>

That idea looks good to me, yes. If that property is set, MM would
just run one signal update query. You could reuse the same polling
logic and just exit polling early as soon as the first successful poll
happens.

As for why QMI has both polling and unsolicited indications, I'm not
sure, don't recall why that was done. Probably to handle devices which
wouldn't report signal updates properly via indications or something,
but not sure. The last similar thing I recall is the Netgear AC341U
not properly reporting network-initiated disconnections via
unsolicited messages, and we tag that one explicitly so that polling
for connection status is performed.

-- 
Aleksander
https://aleksander.es