[PATCH 17/31] build fix: make use of ath_hal_getrtsaggrlimit

[Adrian Chadd]

Yup. But this code originated from our madwifi carrier code.

Hence why it has this in it :)



Sent from my Palm Pre on AT&T
On Mar 29, 2013 5:49 PM, Oleksij Rempel <linux at rempel-privat.de> wrote: 

Am 29.03.2013 19:53, schrieb Adrian Chadd:

> On 29 March 2013 11:10, Oleksij Rempel <linux at rempel-privat.de

> <mailto:linux at rempel-privat.de>> wrote:

>

>         

>         The printf, or the call to ath_hal_getrtsaggrlimit() ?

>

>

>     ath_hal_getrtsaggrlimit(). It make no sense to call it and not check

>     result.

>

>

> Oh, i see what's going on.

>

> In short, we can kill it, as long as we never see AR5416 + AR7010 combo

> NICs.

>

> In long, you have to trace the code. ath_hal_getrtsaggrlimit() is a HAL

> capability call, to fetch the RTS aggrgate limit value. If it actually

> succeeds, it returns HAL_OK and sets the value in  aggr_limit_with_rts

> which is passed in by pointer value. But that capability isn't actually

> processed anywhere. So it doesn't necessarily matter that we don't check

> the return value of the capability call, the point here is

> aggr_limit_with_rts is potentially changed by that call. So it _could_

> in theory be used. :-)

>

> So, for now, just set aggr_limit_with_rts to 0 in ath_buf_set_rate(),

> verify that aggregation still works, and we'll remove this whole check

> later. Setting it to 0 in the definition should quieten the compiler

> warning there.

>

> The reason for the check? AR5416/AR5418 doesn't work with RTS +

> aggregates longer than 8KiB, so the driver has to either limit aggregate

> sizes to 8KiB or less, or disable RTS on longer aggregates. This was

> fixed in subsequent chips.



I'm confused. Aren't AR5416/AR5418 old MACs with draft-n? Two chip 

solutions with PCI/PCIe interface? I think it is unprobable that some 

one will produce AR7010+AR5416+AR2122 or some thing like this. Or i 

misunderstood some thing?



-- 

Regards,

Oleksij


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/ath9k_htc_fw/attachments/20130329/6a0566aa/attachment.html>