The so called "turbo" mode extensions provided by various vendors roughly fall into 3 categories 1. MAC extensions such as frame bursting, aggregation, using more aggressive transmit parameters etc 2. PHY extensions such as using proprietary modulation/coding, MIMO etc 3. RF extensions such as using larger channel width, also sometimes called channel bonding All of these have been adequately addressed by 802.11e, WMM and 802.11n and there exist modes which allow these to be done in a standard compliant and interoperable manner. In my opinion, the linux wireless stack would do well to stay away from the proprietary extensions and thus minimize confusion. At most, we could allow an API for enable/disable turbo mode which would allow the specific driver/firmware to do whatever magic it wants under the hood without polluting the rest of the stack. Thanks, Sandesh -----Original Message----- From: Tomas Winkler [mailto:tomasw@xxxxxxxxx] Sent: Monday, June 18, 2007 5:55 PM To: Johannes Berg Cc: Sandesh Goel; David Lamparter; linux-wireless Subject: Re: phy mode, channel -> freq mapping (was RE: more nl80211/iw tool code comments) On 6/18/07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > Hi, > > > I think it is cleaner to define a parameter called BAND which can take > > values 2.4 GHz, 5 GHz and so on. Then, the combination of BAND and > > CHANNEL will uniquely define the operating frequency. > > <phymode stuff snipped> > > > I wasn't sure if this has already been thought about. I look forward to > > being educated if I am missing something. > > Good point. I hadn't really considered this but a/g or n cards really > make it necessary to distinguish here, and regulatory stuff would also > benefit from defining it that way. > I have to agree that the phymode lost is relevance. and band channel couple has more meaning In this context, what atheros turbo phy mode is? What channel, band does it operate? Thanks Tomas > johannes > > - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
