On 04/13/2015 10:34 PM, Michal Kazior wrote:
On 14 April 2015 at 02:10, Ben Greear <gree...@candelatech.com> wrote:
On 04/13/2015 10:41 AM, Ben Greear wrote:
Looks like I have some more work to do. For any moderately large frames,
I am now dropping the last 16 bytes. Looks like the skb_put_padto logic
was working around a more serious issue...
A better-tested version of kernel and firmware is uploaded now.
Looks like I needed to add a hack to firmware to bump pkt-size by
16 for IBSS + RSN encrypted frames. Not sure exactly why, but seems
to work in light testing.
I removed the skb-padto hack from the kernel, and kernel is rebased on
top of official 4.0 now.
Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
be different from frame length (ath10k_htt_tx(),
htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode[1]
needs to be applied..?
[1]: https://www.mail-archive.com/ath10k@lists.infradead.org/msg00241.html
This IBSS+RSN hack could be done in the kernel, but if my firmware is the only
thing that
needs it, then it is more convenient for me to hack firmware than have it
incompatible with upstream drivers.
If you do find similar problems with other firmware, then certainly a driver
patch is welcome, and I will back out my firmware hack accordingly.
And, it would be nice if someone put some version if your raw-tx patch upstream.
I can also adjust length for raw pkts in firmware too, but again, in many cases
it is better to be similarly broken to existing firmware than to be technically
correct but break compatibility with the driver. If I ever get a 'ct-firmware'
feature flag upstream, then we could of course do the changes to take advantage
of my firmwares differences as needed.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
