Re: [DISCUSS] Implement non standard channel widths

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 3397 bytes --]

On Tue, 2009-08-04 at 02:15 -0400, Pat Erley wrote:

> > Also keep in mind that there _are_ standard uses for smaller bandwidth
> > channels, Jouni has helpfully collected them on
> > http://wireless.kernel.org/en/developers/Documentation/ChannelList
> 
> Yeah, I fully understand that there are other frequency ranges that this
> will be useful in.  My actual goal is using it in the 900mhz spectrum.

Right. But then I think your hw can _only_ operate in 900mhz, so I
suppose you're just saying 'channel 5' anyway, and the hardware has an
offset of, say, 1500 MHz.

> Great, Thanks for the input.  I'm busy tonight, but I'll take a look 
> tomorrow and try to start this, at least in a pseudo mock-up.  I have
> a basic idea how I'll attack this:
> 
> 1. add bitfield
> 2. duplicate all functionality as pertains to bitfield
> 3. update drivers to use bitfield/export their supported modes
> 4. remove old functionality, rename bitfield
> 
> 
> That of course simplifies the actual amount of work it encompases, but
> I believe going with this sort of approach will prevent breaking git
> bisection.

As long as you do it all in one go it won't break bisection either, but
you're welcome to do it this way instead :)

> Would we want the bitfield sparse, to allow for the insertion of other
> modes of operation we hadn't thought of?

I think so, yeah.

>   Also, should it be used like
> how the NL80211_IF_TYPE_* flags are used, in that ALL supported features
> should be added if it's to be used?  Specifically, we're going to assume
> that if a driver exports it's supported modes, it will include stuff like
> NO_HT if it supports operation without HT (which I think ALL devices that
> comply with the 802.11{a,b,g,n} specs would support.  It should probably
> be a long term goal to then add this to all drivers, period, so that
> we won't have to make any assumptions about what a driver supports from
> the mac80211 layer.  

Yes. I just think that's a HUGE amount of work to be doing, hence
proposing the "if (types == 0) types = ..." thing. That way only drivers
who need the new channel types need updating, and we can print a message
there asking drivers to be updated, or so. You could even print the
driver name by following the wiphy's parent device, if present :)

> Also, would we want to add a log message when switching from/to 
> non-standard operating modes?  Something like have a bit that marks the
> highest standard mode, then any additional modes(currently 5/10 mhz only
> could later be extended to adding HT/bonding/xspan in narrower channels)
> would come after that and have something like:
> 
> 
> if(mode > MAX_OPMODE)
> 	printk(some facility, "Switching to opmode %s "
>                               "which is not standardized", mode);
> 
> (Of course, greatly simplified).

I don't know -- most of these modes _are_ (being) standardised.

The biggest issue I see is scanning -- but that currently gives you the
frequency list, so I guess we could extend that to pass the frequency
and channel width, and assume 20mhz if not given. Unfortunately, I used
an array of u32's there so we'd need to introduce a new nl80211
attribute for that.

Also, the channel passed to scan results needs to include the width, so
we don't try to connect to a 20mhz BSS with 5mhz channel width.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]