> > > > + return;
> > > > +
> > > > +mic_fail:
> > > > + cfg80211_michael_mic_failure(sdata->dev, sta->addr,
> > > > + (status->flag &
> > > > RX_FLAG_MCAST)
> > > > ?
> > > > + NL80211_KEYTYPE_GROUP :
> > > > +
> Ok. So it is mainly for encap there needs to be some capability
> advertisement from driver
Obviously, since mac80211 needs to pick the ndo struct to use.
> because for decap driver would use appropriate mac80211 Rx function
> to indicate?
That should be sufficient, no?
In fact, for RX, ass
On Thursday 15 December 2016 03:08 PM, Johannes Berg wrote:
>
>> This rx path only checks if the driver has advertised
>> it's support of 802.11 header encap/decap offload for
>> data frames.
>
> I'm not even sure I see the point in that? Other than that (and the
> various other offload requirement
> This rx path only checks if the driver has advertised
> it's support of 802.11 header encap/decap offload for
> data frames.
I'm not even sure I see the point in that? Other than that (and the
various other offload requirements), it seems that encap/decap could be
considered orthogonal.
> +
Implement rx path which does fewer processing on the
received data frame which has already gone through
802.11 header decapsulation and other functionalities
which require 802.11 header in the low level driver
or hardware. Currently this rx path is restricted
to AP and STA mode, but can be extended
