ar9271 development roadmap
Luis R. Rodriguez
mcgrof at gmail.com
Thu Sep 3 17:42:57 PDT 2009
Note: this e-mail is on a public mailing list.
Figured it'd be good to start reviewing the status of ar9271, review
what areas could use some help and what's coming.
First I'll note my main focus will be on immediate device
functionality. So I'll be making changes to existing HTC/HIF code only
when I see it fit to help with this and a mac80211 driver. So if
others want to focus on general upstream driver cleanup on existing
parts of the driver that is greatly appreciated. Right now I'm quite
happy with leaving HTC/HIF stuff where it is and start focusing on an
initial mac80211 driver to start RX'ing and then eventually TX'ing
and letting others focus on helping cleaning up HTC/HIF stuff. I'll
soon commit what I have so far, as soon as it compiles. Then general
help with mac80211 stuff will be greatly welcomed.
If you would like to help with general cleanup please take a look at
htc.c, hif_usb.c and respective header files, all that could use some
more cleanup up for upstream inclusion, this includes coding style,
function renaming to something clearer and general enhancements. If
you'd like to help with typedef removals I've written some script to
help with that . I've been using it heavily already throughout the
driver and so far its worked quite nicely. If you see issues with that
script please send me a patch, I'd actually like to see that simple
script upstream as I expect other Linux driver projects could benefit.
Enhancements to existing hif_usb.c could be to use usb anchors, I
think that would help to remove complex loops we currently use to free
Then there are general architectural issues with HTC/HIF/WMI present
on the code which I think some may like to address to help with
sharing code between ar9271 and ar6k. What the likelyhood of sharing
is remains somewhat obscure to me yet as I only recently started
getting myself familiar with HTC/HIF/WMI and from what I can tell ar6k
uses something like Ethernet frames for data transmissions as ar6k is
a fullmac device, ar9271 however is a softmac device and we do intend
on passing raw 802.11 frames between host and target. Another
architectural issue I see with sharing ar9271 HTC code between other
HTC type devices is HTC seems to be designed to support one type of
device at a time, even though HTC itself is built as its own module.
Also keep in mind that the WMI command APIs used on ar6k and ar9271
may vary, I haven't reviewed this yet, and, this will likely loosely
change on future chipsets. These considerations make me wonder if to
incline to supporting our own HTC code for each wireless HTC module or
really trying to share. Realistically it seems that we may have to
just consider keeping these separately for each wireless module for
now but I welcome someone to take a look if they are interested.. If
you are interested you can start reviewing ar6k  HTC/HIF code and
see what things can really be shared between it and ar9271's 
HTC/HIF. If no one makes a determination on this by the time its time
to go upstream I'll just merge HTC/HIF code into a singular part of
the ar9271 device driver as it just currently won't support more than
one device type anyway.
We do have sample hardware to provide to interested developers but
please do not that I'd like to ensure we don't send these to just
anyone that says they want one or who thinks they can commit. If you
are a current active upstream wireless contributor and you tell me you
need one I'll take it for granted you will send patches and get you
one, if you are interested in development but are currently not an
active contributor please start looking at code first and then start
sending patches; there's plenty to do already even without hardware;
then we can consider sending you one.
If you have any questions or ideas please let me know.
More information about the devel