Hi Denis,

>> Looking to the modem manager, the priority is indeed to retrieve the SID
>> using the qcdm port com (thanks to the result of a radio status query).
>> In case of error, there is however a fallback to use the AT command
>> +CSS. Also, if no qcdm port is available, the SID is retrieved  by using
>> this AT command (please refer to 'legacy_get_serving_system').
>>
>> Note that in modem manager, there is also a special treatment for Huawei
>> modem which use the IS-707-A format (no band and class).
>
> I also noticed various comments stating that +CSS does not report any
> information when registered to EV-DO and it seems that the Huawei driver
> doesn't even bother using fallback mechanisms for EVDO capable hardware
> in the first place.  But maybe I'm not reading the code right...

You're right. I missed this point as this consideration seems rather 
linked with the registration state query.
In fact, I started to see the code from the network manager applet to 
see how the SID was retrieved.
That's why, I looked only for the 'GetServingSystem' method in modem 
manager. This method is implemented in the generic part and the flag 
'reg_try_css' is not checked here.

In fact, this problematic is not explicitely considered when getting the 
serving system in modem manager as the query is done first on the qcdm 
port. So, I presume that this port should always be available with EVDO 
capabale hardware.
So, the qcdm part seems mandatory.


>
>>
>> So far, the AT command "Serving system" seems relevant. Now, do you
>> expect us to communicate also through the qcdm port when using cdma modem?
>
> Have you tested that your theories work?
Yes, I checked locally with huawei cdma dongles and the speedup SU 7300 
that the command "AT+CSS?" was effectively supported.
I tested also remotely (through SSH with a machine in China where a 
huawei cdma dongle is plugged) that the SID was correctly returned when 
registered.

As you can see below:

ofonod[30357]: Modem: < \r\n^MODE: 
2\r\r\n\r\r\n^RSSILVL:60\r\r\n\r\r\n^HRSSILVL:0\r\n
ofonod[30357]: PCUI: < \r\n^MODE: 
2\r\r\n\r\r\n^RSSILVL:60\r\r\n\r\r\n^HRSSILVL:0\r\n
ofonod[30357]: Modem: > AT^SYSINFO\r
ofonod[30357]: Modem: < \r\n^SYSINFO:2,255,0,2,1\r\n\r\nOK\r\n
ofonod[30357]: drivers/cdmamodem/network-registration.c:parse_sysinfo() 
2, 255, 0
ofonod[30357]: Modem: > AT+CSS=?\r
ofonod[30357]: Modem: < \r\n?, 13840\r\n\r\nOK\r\n
ofonod[30357]: 
drivers/cdmamodem/network-registration.c:serving_system_cb() serving 
system: SID 13840
ofonod[30357]: src/cdma-netreg.c:serving_system_callback() Serving 
system Identifier: 13840

Here the provider name is not found. Maybe the provider info file placed 
in the remote desktop is not sufficiently populated.


Right now I'm seeing you
> making lots of assumptions, and moving code from the huawei specific
> driver to some generic driver when in fact no such generality exists.
> CDMA does not have an AT command standard ;)

In fact, I applied the same approach as for the atmodem driver.
We only have one network-registration driver which is taking care of all 
manufacturer specific commands (as for Huawei).
As the AT command '+CSS' is supported by both Speedup cdma And Huawei 
cdma, I took the initiative indeed to move the specific huawei part into 
a generic driver.
Also, the AT command AT+CSS is implemented in the generic part in modem 
manager.

>
> And yes, if the AT command does not do what we need, then using QCDM
> would be required.

As stated above, I will start to implement the QCDM part as this should 
be required when using EVDO capable hardware.

Thanks.

Regards,

Philippe.