Bug 100000

Three bugs here, I think:

1) WCDMA subsystem L1 state 0x08 (4th byte from the end) is QCDM_WCDMA_L1_STATE_DEACTIVATE which MM doesn't recognize as an active WCDMA state, and thus ctx->wcdma_open=0 and MM assumes GPRS.  But turns out that's wrong, the state should really be "PCH_SLEEP" which is a valid WCDMA connected state.  I'll update libqcdm.

2) If the sysmode is QCDM_CMD_CM_SUBSYS_STATE_INFO_SYSTEM_MODE_WCDMA (QCDM system mode 5) MM shouldn't fall back to GPRS since that enum value indicates GPRS is not supposed to be enabled (as opposed to MODE_GSM and MODE_GW).

3) Why are we bothering to check QCDM for access tech when MBIM can already provide that? :)

Patches sent to list for the first two items.

[PATCH 1/2] libqcdm: fix WCDMA L1 Manager states
[PATCH 2/2] broadband-modem: fix QCDM access tech reporting for WCDMA system modes

> 3) Why are we bothering to check QCDM for access tech when MBIM can already
> provide that? :)

Looks like the MBIM implementation doesn't subclass "load_access_technologies" and therefore we just take what's in the generic MMBroadbandModem.

IIRC there isn't an explicit MBIM message to query this, so should we just cache whatever access tech we get reported via other messages, and then return the cached value in a subclassed "load_access_technologies"?

(In reply to Dan Williams from comment #2)
> Patches sent to list for the first two items.
> 
> [PATCH 1/2] libqcdm: fix WCDMA L1 Manager states
> [PATCH 2/2] broadband-modem: fix QCDM access tech reporting for WCDMA system
> modes

+1 for both

(In reply to Aleksander Morgado from comment #3)
> > 3) Why are we bothering to check QCDM for access tech when MBIM can already
> > provide that? :)
> 
> Looks like the MBIM implementation doesn't subclass
> "load_access_technologies" and therefore we just take what's in the generic
> MMBroadbandModem.
> 
> IIRC there isn't an explicit MBIM message to query this, so should we just
> cache whatever access tech we get reported via other messages, and then
> return the cached value in a subclassed "load_access_technologies"?

Yeah, that's what should happen.  Icera kinda does this already (but only because the unsolicited regex captures the solicited command response too).

But really, couldn't we just set the load_access_tech/finish hooks to NULL and let the unsolicited messaging handle access tech updates?

(In reply to Aleksander Morgado from comment #4)
> (In reply to Dan Williams from comment #2)
> > Patches sent to list for the first two items.
> > 
> > [PATCH 1/2] libqcdm: fix WCDMA L1 Manager states
> > [PATCH 2/2] broadband-modem: fix QCDM access tech reporting for WCDMA system
> > modes
> 
> +1 for both

Pushed to git master, 1-6, and 1-4.

(In reply to Dan Williams from comment #5)
> (In reply to Aleksander Morgado from comment #3)
> > > 3) Why are we bothering to check QCDM for access tech when MBIM can already
> > > provide that? :)
> > 
> > Looks like the MBIM implementation doesn't subclass
> > "load_access_technologies" and therefore we just take what's in the generic
> > MMBroadbandModem.
> > 
> > IIRC there isn't an explicit MBIM message to query this, so should we just
> > cache whatever access tech we get reported via other messages, and then
> > return the cached value in a subclassed "load_access_technologies"?
> 
> Yeah, that's what should happen.  Icera kinda does this already (but only
> because the unsolicited regex captures the solicited command response too).
> 
> But really, couldn't we just set the load_access_tech/finish hooks to NULL
> and let the unsolicited messaging handle access tech updates?

Hah, yeah, probably, let me test that.

(In reply to Aleksander Morgado from comment #7)
> (In reply to Dan Williams from comment #5)
> > (In reply to Aleksander Morgado from comment #3)
> > > > 3) Why are we bothering to check QCDM for access tech when MBIM can already
> > > > provide that? :)
> > > 
> > > Looks like the MBIM implementation doesn't subclass
> > > "load_access_technologies" and therefore we just take what's in the generic
> > > MMBroadbandModem.
> > > 
> > > IIRC there isn't an explicit MBIM message to query this, so should we just
> > > cache whatever access tech we get reported via other messages, and then
> > > return the cached value in a subclassed "load_access_technologies"?
> > 
> > Yeah, that's what should happen.  Icera kinda does this already (but only
> > because the unsolicited regex captures the solicited command response too).
> > 
> > But really, couldn't we just set the load_access_tech/finish hooks to NULL
> > and let the unsolicited messaging handle access tech updates?
> 
> Hah, yeah, probably, let me test that.

Pushed to master, mm-1-6 and mm-1-4.