Yup. But this code originated from our madwifi carrier code. Hence why it has this in it :) <span style="font-family:Prelude, Verdana, san-serif;"> <span id="signature"><div style="font-family: arial, sans-serif; font-size: 12px;color: #999999;">Sent from my Palm Pre on AT&T</div> <span style="color:navy; font-family:Prelude, Verdana, san-serif; "><hr align="left" style="width:75%">On Mar 29, 2013 5:49 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:  Am 29.03.2013 19:53, schrieb Adrian Chadd:

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

<br>> <mailto:linux@rempel-privat.de>> wrote:

<br>>

<br>>         

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

<br>>

<br>>

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

<br>>     result.

<br>>

<br>>

> Oh, i see what's going on.

<br>>

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

<br>> NICs.

<br>>

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

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

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

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

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

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

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

<br>> in theory be used. :-)

<br>>

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

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

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

<br>> warning there.

<br>>

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

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

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

> fixed in subsequent chips.

<br>

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

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

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

misunderstood some thing?

<br>

<br>-- 

<br>Regards,

<br>Oleksij

<br></span>