From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 17:13:05 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0334106575C for ; Wed, 22 Dec 2010 17:13:05 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f48.google.com (mail-bw0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id 35BDD8FC17 for ; Wed, 22 Dec 2010 17:13:04 +0000 (UTC) Received: by bwz8 with SMTP id 8so5535175bwz.7 for ; Wed, 22 Dec 2010 09:13:04 -0800 (PST) Received: by 10.204.60.79 with SMTP id o15mr6053406bkh.25.1293036634420; Wed, 22 Dec 2010 08:50:34 -0800 (PST) Received: from julie.lab.techwires.net (dslb-094-217-133-069.pools.arcor-ip.net [94.217.133.69]) by mx.google.com with ESMTPS id q18sm5145048bka.15.2010.12.22.08.50.32 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 08:50:32 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Wed, 22 Dec 2010 17:49:05 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012221749.05927.bschmidt@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Initial 802.11n / ath support merge plan X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:13:05 -0000 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