From bjorn at mork.no  Tue Nov  8 14:53:28 2016
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Tue, 08 Nov 2016 15:53:28 +0100
Subject: Documenting common firmware bugs: NTB header sequence number
Message-ID: <87mvhaja53.fsf@miraculix.mork.no>

So the NCM spec says:

 wSequence - Sequence number. The transmitter of a block shall set this
   to zero in the first NTB transferred after every “function reset”
   event, and shall increment for every NTB subsequently
   transferred. The effect of an out-of-sequence block on the receiver
   is not specified. The specification allows the receiver to decide
   whether to check the sequence number, and to decide how to respond if
   it’s incorrect. The sequence number is primarily supplied for
   debugging purposes.

Right.  Like there ever has been any point writing something as loose as
that in a spec.

I just happend to enable the debugging message we've left in the driver,
and was surprised to see it triggered reliably at every device wakeup on
the EM7455:

 Nov  8 15:36:43 miraculix kernel: [52905.711507] cdc_ncm_rx_verify_nth16: cdc_mbim 1-2:1.12 wwan0: sequence number glitch prev=30 curr=0
 Nov  8 15:37:13 miraculix kernel: [52936.010764] cdc_ncm_rx_verify_nth16: cdc_mbim 1-2:1.12 wwan0: sequence number glitch prev=129 curr=0
 Nov  8 15:37:39 miraculix kernel: [52962.064203] cdc_ncm_rx_verify_nth16: cdc_mbim 1-2:1.12 wwan0: sequence number glitch prev=13 curr=0


So it seems Qualcomm "forgot" to save the current sequence number when
going to sleep, causing the number to be reset every time we resume the
device. Oh well. Vendor ignored a debugging-only part of the spec.
Colour me surprised :)

I guess we could save ourselves a bit of code and data by just ripping
out everything related to wSequence from the driver.  It's obviously
useless. And we do spend quite a few cycles saving and comparing it.


Bjørn