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:
signature.asc
Description: This is a digitally signed message part
