MS specific device services

Wed Feb 26 02:32:52 PST 2014

Aleksander Morgado <aleksander at aleksander.es> writes:
> On 25/02/14 09:43, Ben Chan wrote:
>> I've made a few patches that implement the MS specific device services
>> (i.e. Firmware ID and Host Shutdown). Unfortunately, the specifications of
>> these services don't follow a consistent naming convention. I'm thinking we
>> could harmonize the names as follows:
>> 
>>   MBIM_SERVICE_MS_FWID  (instead of MBIM_SERVICE_MSFWID)
>>   MBIM_CID_MS_FWID_FIRMWAREID
>> 
>>   MBIM_SERVICE_MS_HOSTSHUTDOWN
>>   MBIM_CID_MS_HOSTSHUTDOWN_HOSTSHUTDOWN   (instead
>> of MBIM_CID_MS_HOSTSHUTDOWN_MSHOSTSHUTDOWN)
>> 
>> And for the mbimcli actions:
>> 
>>   mbimcli --ms-query-firmware-id  (instead of --ms-fwid-query-firmwareid)
>>   mbimcli --ms-host-shutdown  (instead of --ms-hostshutdown-hostshutdown)
>
> I already thought about these, and my idea was to completely avoid the
> name duplications in the service and command ids, and really rewrite
> them ourselves; so something like:
>
> MBIM_SERVICE_MS_FIRMWARE_ID
> MBIM_CID_MS_FIRMWARE_ID_GET
>
> MBIM_SERVICE_MS_HOST_SHUTDOWN
> MBIM_CID_MS_HOST_SHUTDOWN_NOTIFY
>
> The "Get" and "Notify" names are really made up, but given that these
> services only have one command each, it's probably not a big deal.
>
> And then for the mbimcli actions:
> --ms-firmware-id-get
> --ms-host-shutdown-notify
>
> BTW, do you have any device supporting these? None of the ones I know of
> have them implemented.

The MC7710 with 'SWI9200X_03.05.24.00ap' firmware sort of implements
them, but the firmware-id is all zeroes, so I guess that's just a dummy
implementation.

bjorn at nemi:~$ mbimcli -d /dev/cdc-wdm0   --query-device-services
[snip]
                          Service: 'unknown'
                             UUID: [d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3]:
                      DSS payload: 0
                Max DSS instances: 0
                             CIDs: 1

                          Service: 'unknown'
                             UUID: [883b7c26-985f-43fa-9804-27d7fb80959c]:
                      DSS payload: 0
                Max DSS instances: 0
                             CIDs: 1

                          Service: 'unknown'
                             UUID: [e9f7dea2-feaf-4009-93ce-90a3694103b6]:
                      DSS payload: 0
                Max DSS instances: 0
                             CIDs: 1

                          Service: 'unknown'
                             UUID: [5967bdcc-7fd2-49a2-9f5c-b2e70e527db3]:
                      DSS payload: 0
                Max DSS instances: 0
                             CIDs: 1, 2, 3, 4, 9, 10, 11

Sending MBIM_CID_MS_FWID_FIRMWAREID:
03 00 00 00 30 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 e9 f7 de a2 fe af 40 09 93 ce 90 a3 69 41 03 b6 01 00 00 00 00 00 00 00 00 00 00 00 

I receive:
03 00 00 80 40 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 e9 f7 de a2 fe af 40 09 93 ce 90 a3 69 41 03 b6 01 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

That translates to
 FirmwareID:   00000000-0000-0000-0000-000000000000

The MBIM_CID_MS_HOSTSHUTDOWN does something useful though.
Sending: 

03 00 00 00 30 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 88 3b 7c 26 98 5f 43 fa 98 04 27 d7 fb 80 95 9c 01 00 00 00 01 00 00 00 00 00 00 00 

I receive a "success" reply:

03 00 00 80 30 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 88 3b 7c 26 98 5f 43 fa 98 04 27 d7 fb 80 95 9c 01 00 00 00 00 00 00 00 00 00 00 00 

followed by a couple of notification showing that the modem detached
from the network and disabled its radios:

07 00 00 80 48 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 3e c2 aa e6 df 0a 00 00 00 1c 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

07 00 00 80 5c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 3e c2 aa e6 df 09 00 00 00 30 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00

07 00 00 80 34 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 a2 89 cc 33 bc bb 8b 4f b6 b0 13 3e c2 aa e6 df 03 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00

The end result is that the modem is in software controlled off state,
but still powered and alive on the USB bus so we are able to restore
functionality by simply turning it on again.

bjorn at nemi:~$ mbimcli -d /dev/cdc-wdm0 --query-radio-state 
[/dev/cdc-wdm0] Radio state retrieved:
             Hardware Radio State: 'on'
             Software Radio State: 'off'

But I believe this is firmware specififc behaviour.  There is nothing in
the MS document guaranteeing that we will be able to talk to the modem
again after this command without help from the host system (using some
power switch external to the modem).

FWIW, I fail to see any usecase for MBIM_CID_MS_HOSTSHUTDOWN in Linux.

We cannot safely use it from userspace because we have to be able to
cancel a shutdown. And we do not know whether we will be able to power
on the modem again after this command.  Maybe the user only wanted to
stop ModemManager...

And we can do what the MC7710 firmware does with standard MBIM commands.
We do not have to resort to some MS specific commands without a well
defined behaviour.

If MS had been writing proper software, then they would have implemented
the standard detach + sw radio off instead of defining a new service for
this.  I propose that Linux does better and just ignore the HOSTSHUTDOWN
service.

The MS_FWID service seems like a useful one on the other hand, if we ever
implement any upgrade functionality for some modem supporting this
service.

Bjørn