Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Dec 2010 17:49:05 +0100
From:      Bernhard Schmidt <bschmidt@freebsd.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Initial 802.11n / ath support merge plan
Message-ID:  <201012221749.05927.bschmidt@freebsd.org>
In-Reply-To: <AANLkTi=e4u3BAzodoE7DAbuC3S2bWNwZ_0xUaDTQqN8L@mail.gmail.com>
References:  <AANLkTi=e4u3BAzodoE7DAbuC3S2bWNwZ_0xUaDTQqN8L@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 22 December 2010 16:24:01 Adrian Chadd wrote:
> Hi all,
> 
> I'd like to start the process for merging in my initial 802.11n
> support into -HEAD and -8.
> 
> My 802.11n work can be broken into a few chunks. The details aren't
> exhaustive, but they give a good idea of the breadth of the
> development I've been doing here.
> 
> What I'd like to do is commit bits and pieces of work, rather than
> just doing a big "code drop" that changes a whole lot of stuff. Then
> let it bake for time, let users test it, etc, before moving onto the
> next bits.
> 
> * net80211 work:
>   + mostly to handle some of the 802.11n station related bits - enough
> for 2.4ghz HT/20 association. I've not tried 5ghz 11n; and HT/40
> doesn't yet seem to work for whatever reason;
> 
> * if_ath HAL work:
>   + move 91xx and 92xx support into different chipset directories in
> the ath_hal directory
>   + added support for the AR9100
>   + merged in some changes from Linux ath9k
>   + some chipset reset path refactoring/restructuring
>   + a set of "hardware ops" to abstract out the per-chipset
> differences of the AR5416 and later chips - again, based on ath9k - to
> make it easier in the future to port ath9k code to our HAL
>   + added new hooks to tidy up handling TX descriptor completion for
> multi-rate stuff
> 
> * ath_rate work:
>   + ath_rate_sample now knows about _basic_ 802.11n stuff; enough to
> TX MCS rates
>   + ath_rate_sample now calls a HAL method to pull the multi-rate TX
> completion data out, rather than fondling the TX descriptors directly
>   + ath_rate_sample provides the TX rate list as an array, rather than
> directly calling the HAL to set up the TX descriptor
> 
> * if_ath work:
>   + refactored out the TX, RX, beacon, TDMA and debug code into
> separate source files
>   + enabled some 802.11n related bits facing net80211
>   + added basic non-aggregate 11n TX support (incomplete so far)
>   + disabled multicast hw crypto for now - this breaks AES-CCMP
> encryption which is needed for 11n WPA
> 
> What I'd like to do in the short short term:
> 
> * merge in the net80211 changes into HEAD, then backport those to
> RELENG_8. This sets up the scene to support 802.11n in station mode,
> but shouldn't break existing setups;
> * maintain the ath/ath_hal/ath_rate stuff in my GIT tree for now, and
> release drop-in snapshots for people to play with (and I've verified
> that the code does work under RELENG_8 :-);
> 
> What I'd like to do moving forward, beginning in early Jan 2011:
> 
> * Bring over the changes to the rate control modules to tidy up how
> they fondle the hardware - these changes are reasonably self-contained
> * Bring over the ath_hal changes. This brings over the AR9100 support,
> the re-factored HAL structure and changes from ath9k. I could try to
> separate that work out into separate patches but it's likely going to
> be a lot of of work for little gain.
> * Let users then test the AR5416, AR9160, AR9280, AR9285 support - and
> then find/fix whatever bugs crop up there (and the bugs that still
> exist!)
> * Finally, once that's done, look at attacking the if_ath code to
> enable the initial 11n support.
> 
> What do people think?

go, go, go!

Let me know if I can help out somewhere.

-- 
Bernhard



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012221749.05927.bschmidt>