
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
The below qca6290 and qca8074 folder has c files defining functions and structures to hold target specific definitions to handle differences between chips with respect to hal. Please ensure changes get applied to all platform specific files if the fixes are generic and applicable to all the folders. qca6290 hal_6290_rx.c - rx related target specific function hal_6290_srng_table.c - holds hw srng table and hal hw reg offsets array hal_6290_tx.c - tx related target specific function qca8074 hal_8074_rx.c - rx related target specific function hal_8074_srng_table.c - holds hw srng table and hal hw reg offsets array hal_8074_tx.c - tx related target specific function