Hi Brian,
hard_header_len provides limitations for things like AF_PACKET, such that
we don't allow transmitting packets smaller than this.
OK; However, are we not supposed to mention hard_header_len also?
needed_headroom provides a suggested minimum headroom for SKBs, so
that we can trivally add our headers to the front.
The latter is the correct field to use in this case, while the former mostly just
prevents sending small AF_PACKET frames.
In any case, mwifiex already does its own bounce buffering [1] if we don't
have enough headroom, so hints (not hard limits) are all that are needed.
This is the essentially the same bug (and fix) that brcmfmac had, fixed in
commit cb39288fd6bb ("brcmfmac: use ndev->needed_headroom to reserve
additional header space").
OK; I read this commit:
"... According to definition of LL_RESERVED_SPACE() and hard_header_len, we should use hard_header_len to reserve for L2 header, like ethernet header(ETH_HLEN) in our case and use needed_headroom for the additional headroom needed by hardware..."
So, does it mean, hard_header_len is already considered by upper layer?
Regards,
Ganapathi