On 08/20/2013 07:36 PM, Felix Fietkau wrote:
On 2013-08-20 10:15 AM, Arend van Spriel wrote:
Hi Felix,
I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck
support and only change brcmsmac.
I prefer having a flag to enable it over one to disable it, because it
fits better with the existing flags. Also, future drivers may not always
be properly prepared to handle CCK in A-MPDU sessions either.
Ok. It just looked a bit strange that a problem in brcmsmac results in
changing other drivers.
By the way, I took a short look at brcmsmac and found more issues that
you should look into if you want to fix this.
First of all, you should probably make sure that the hardware does not
try to send an A-MPDU using a CCK rate (prepare it as a single frame in
brcms_c_ampdu_add_frame). It also does not seem to have any checks to
ensure that rate control probing frames are not aggregated.
Thanks, Felix. I also noticed that our proprietary driver has code in
place for these scenarios.
Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
