Re: [ath5k-devel] [PATCH 5/5] ath5k: Implement mac80211 callback set_coverage_class

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Tue, Dec 15, 2009 at 01:35:01PM -0800, Lukáš Turek wrote:
> On 15.12.2009 19:50 you wrote:
> > Can you move this last line setting the sc->ah->ah_coverage_class
> > to ath5k_hw_set_coverage_class() instead?
> ath5k_hw_set_coverage_class() is also called after interface reset:
> ath5k_hw_set_coverage_class(ah, ah->ah_coverage_class);
> 
> So it would be quite strange if it set the value again...
> But I see your point, and don't see a better solution.

What I meant was not for you to pass the ah->ah_coverage_class to
ath5k_hw_set_coverage_class() but instead to pass the value obtained
from mac80211 and let ath5k_hw_set_coverage_class() itself set it on
ah.

> > Also -- if an ath_hw_set_coverage_class(common, coverage_class) can be
> > defined on drivers/net/wireless/ath/hw.c along with:
> >
> > ath_hw_set_slot_time(common, slot_time),
> > ath_hw_set_ack_timeout(common, ack_timeout);
> > ath_hw_set_cts_timeout(common, cts_timeout);
>
> Unfortunately the functions are really hardware specific, they write a 
> register that even differs between chip versions, and also depend on chip 
> clock rate.

Thanks for checking, I just wanted to elaborate as to how we can share code
and to because of that it seems like a good idea to remain consistant and
treat settings ah-> variables in hw code alone.

The less we muck with ah-> settings on base.c for ath5k the more well kept
and separated the actual hw code is. This really will only serve purpose
to later merge mow hw code between ath9k/ath5k. How much we end up sharing
remains to be seen, I don't mind the current split we have but if we do
see something obviously common it makes sense to just stuff it in when we
get a chance to ath.

> It would be possible to move ath_hw_set_coverage_class() to ath to share the 
> calculation, but that would require exporting six functions from the modules.
> 
> > Wonder if ar9170 can support setting these too.
>
> It seems it supports setting slot time, but I don't see a register with ACK 
> timeout, which is required too.

Thanks for checking, I was lazy, and just curious. Reason for asking was if
it could use at least caching the coverage class a hardware parameter we
can stuff it into ath_common just as we do with the bssid_mask and stuff.
Even if its just shared between ath5k and ath9k its still worth stashing it
there if both will use it.

Since tuning cts timeout, ack timouet and slot time may not be an operation
which we do that often it would still not be so bad to just stuff a generic
helper for ath5k/ath9k into ath which will handle the different hw revisions
itself.

  Luis