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

Oleksij Rempel linux at rempel-privat.de
Fri Mar 29 17:49:39 EDT 2013


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



More information about the Ath9k_htc_fw mailing list