[RFC] aleksander/dms-0x5556 branch

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:

> Hey,
>
> We've seen how the DMS 0x5556 means different things depending on the
> vendor that implemented it:
>
>  * For Sierra Wireless modems, it returns information about the
> currently running firmware.
>  * For HP modems, it allows changing the operating mode, e.g. to
> reboot into fastboot mode that allows firmware download, or to switch
> between QMI and MBIM implementations.
>
> I've implemented some support for "vendor-specific" implementations of
> the same commands, in order to support different variants of the DMS
> 0x5556. E.g. both qmi_client_dms_swi_get_current_firmware() and
> qmi_client_dms_hp_change_device_mode() will issue the DMS 0x5556
> command, but the former expects TLVs in the result and the latter
> expects TLVs in the input. i.e. the processing of the command and the
> contents expected in request and response are different.
>
> With the changes done, the "printable" contents of the message as well
> as the "version support check" are treated as vendor-specific, and
> will vary depending on the format specified for the message in the
> database.
>
> Vendors are specified by a new "vendor" tag in the JSON description of
> the QMI message (request/response), given as a uint16 in hex (i.e.
> just place the USB vid here).
>
> No support for vendor-specific QMI indications yet as that's a bit trickier.
>
> The branch also contains an update in qmi-firmware-update in order to
> use "SWI Get Current Firmware" command before and after the update,
> i.e. for the last report after the operation.
>
> What do you guys think?

Sounds like a good plan to me.  I have always assumed that all these
0x55.. requests were "vendor-specific", including the "FCC Auth"
request.

> P.S.: the only thing I'm not much convinced of is the enumeration I
> prepared for the "DMS HP Change Device Mode" message, mainly because
> the items in the enumeration are just taken out of my tests with the
> HPlt4120. I just didn't want to have an API method (and qmicli
> command) expecting a "generic integer". Maybe we should just list in
> the enum the "fastboot" entry, which is the one used in HP firmware
> ugprade for sure?

I think it's best to be careful here until we have more test-data.
These numbers could be static and have the same meaning across different
modems, like the Sierra Wireless UDUSBCOMP values.  But they could also
be dynamically allocated and therefore product, or even firmware
revision, specific.

Better limit the enum to the well known "fastboot" entry for now.


Bjørn