When the length of a 802.11 frame is more than the
size of the posted receive buffers, it is split across
multiple buffers, which have to be accumulated before
submitting to network stack.
For all-but-last buffer which are used for the above
mentioned large 802.11 frame, the MSDU_CONTINUATION
flag will be set indicating that remaining data of the
same msdu has been DMA'ed to the next buffer.
The current implementation in monitor-1.0 works for
legacy chipsets, where MSDU_START tlv is available and
hence the aforementioned information was available in
all the buffers containing the large 802.11 frame.
For kiwi target, there is no MSDU_START tlv, and hence
a lot of information eg: mpdu_len_err, decap_format and
l2_hdr_offset are not available in the buffers where the
msdu_continuation flag is set. This leads to an attempt
of mpdu_restitch using incorrect data from tlv, and hence
the mpdu_restitch fails for such large 802.11 frame.
Fix this issue for kiwi target, by gathering all these
information which are available in the last buffer and
are used to process/accumulate the entire 802.11 frame.
Change-Id: I1c4fc9fd574c1c5fabc845407aa6f2d990c60906
CRs-Fixed: 3261494
27f5c5e7b8