On Tue, 2016-02-23 at 17:15 +0100, Johannes Berg wrote:
> > > Perhaps we could live with this being done only for the fast-xmit
> > > case?
> > I don't think we should pass padded vs non-padded frames depending
> > on
> > whether fast-xmit was used. The non-fast-xmit codepath could simply
> > do
On Tue, 2016-02-23 at 15:53 +0100, Felix Fietkau wrote:
> > Perhaps we could live with this being done only for the fast-xmit
> > case?
> I don't think we should pass padded vs non-padded frames depending on
> whether fast-xmit was used. The non-fast-xmit codepath could simply
> do the memmove at
On 2016-02-23 15:29, Johannes Berg wrote:
> On Fri, 2016-02-19 at 11:01 +0100, Janusz Dziedzic wrote:
>> HW/driver should set NEED_ALIGNED4_SKBS flag in case
>> require aligned skbs to four-byte boundaries.
>> This affect only TX direction.
>>
>> Padding is added after ieee80211_hdr, before
On Fri, 2016-02-19 at 11:01 +0100, Janusz Dziedzic wrote:
> HW/driver should set NEED_ALIGNED4_SKBS flag in case
> require aligned skbs to four-byte boundaries.
> This affect only TX direction.
>
> Padding is added after ieee80211_hdr, before IV/LLC.
I'm still not super happy with how invasive
HW/driver should set NEED_ALIGNED4_SKBS flag in case
require aligned skbs to four-byte boundaries.
This affect only TX direction.
Padding is added after ieee80211_hdr, before IV/LLC.
Before we have to do memmove(hdrlen) twice in the
dirver. Once before we pass this to HW and next
in tx
