Hi,
I am working on a research project which needs to change the channel
width to 5,10 and 40MHz. Ive been looking through the mailing lists and
there seems to be some interest in having an API built for this.
Would it be possible for someone to please outline the steps needed to
enable 5,10,40 MHz channels? I am not looking for a clean implemented
API, just whatever hack is required to change the PLL clock, modify
PHY/RF settings (as mentioned in the thread below) in order to get this
to work.
Thanks very much for your help
regards,
Aditya Bhave
Pavel Roskin wrote:
On Sat, 2009-08-29 at 07:51 +0300, Nick Kossifidis wrote:
a) X.R.: eXtended Range is a set of proprietary rates and some extra
techniques (various hw tweaks etc) to enable long distance, low
bandwidth links.
I'm not interested because it's ugly and we don't have a good reference
implementation. Besides, there must be a reason why it's not in the
FreeBSD HAL. Either it's patented or Atheros was ashamed to expose that
code.
b) OFDM-only g settings for AR5211: AR5211 chips have support for
draft-g (eg. no dynamic CCK/OFDM modulation, only OFDM). I don't know
if we want to support it or not, removing the settings will save us
some space and since it's a draft g implementation i don't think there
are many compatible APs out there. Is there any possibility to support
draft-g on mac80211/cfg80211 ? If not we can just drop it else it's
just some extra data, no big deal.
If there is a simple way to support it, let's do it. I think having
"pure G" may be a good idea in some situations, regardless of the
hardware limitations. But that's something that should be done in
mac80211.
I would keep the initialization code for now.
That said, AR5210 and AR5211 are so rare, that we might consider
splitting them into separate drivers that would not be actively
maintained.
c) Half/quarter rate channels (10/5MHz width) and turbo mode (double
rate - 40MHz width): Hw can transmit with different channel width
allowing us to operate on half, quarter or double rate (also called
turbo mode).
It would be nice to be able to receive on wide and narrow channels, at
least in the monitor mode. Generally, "be liberal in what you accept,
and conservative in what you send".
We'll need some API to set the bandwidth and radiotap flags to
communicate the bandwidth to the recipient.
d) Fast frames: Hw can tx/rx jumbo frames of 3kbytes+ so fast frame
aggregation is a way to make use of that hw feature by sending 2
frames together (for more infos check out super ag white paper).
Likewise, it would be nice to receive them.
e) Compression: Hw can do on-chip compression/decompression using
standard Lempel Ziv algorithm per tx queue, MadWiFi implements this
and uses a vendor IE to let others know that it supports this feature
(same IE is used for all capabilities, fast frames, XR etc).
Same thing here, as long as we can reuse the existing kernel code for
decompression.
--
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
