Hi, Thanks for your prompt responses.
Another member posted some time back that the 'iw' command can set the bandwidth to be 40 MHz in addition to the default 20. So I guess user-level API support is already built in for this kind of change. Don't we just need to extend it's implementation to accept bandwidths (within the ISM band) of any width? I understand there will also be regulatory concerns, but for my research work at the moment, I was wondering how many software changes (hacks) need to be done in ath5k/9k in order to make this work? Thanks regards, Aditya Bhave Pavel Roskin wrote: > On Thu, 2009-08-20 at 04:41 -0700, shashi raj singh wrote: > >> Hi Aditya >> >> I think by changing PLL control register setting u sud b able to achieve >> your goal.(also u will require som sw changes) >> look in reg.h of ath5k >> > > The question is not how to do it in the chipset. The question is how to > make it properly on all layers. Should we use the same channel numbers > for narrow bandwidth or different channels? How should the userspace > set the bandwidth? Are there any regulatory considerations? How can we > integrate the new functionality smoothly with the already existing > support for setting 40 MHz bandwidth for 802.11n? How should the > collision avoidance work? > > I think linux-wirel...@vger.kernel.org would be a better place to > discuss it. Once the design issues are resolved, ath5k would be > probably the first driver to implement the narrow channels. > > But implementing a hack specific to ath5k won't be appreciated upstream. > > _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
