On Fri, 2012-09-14 at 13:48 +0530, Mahesh Palivela wrote: > > Although VHT complicates the regulatory checks, to the extent you > > check for valid 20 MHz IEEE channels in between a VHT wide channel, > > the IEEE spec actually only allows in practice certain VHT > > arrangements. I've asked for shiny diagrams that have this laid out > > clearly and simple but unfortunately we do not have one, but such > > simple static arrangements are apparently specified on the spec, its > > not clear to me where exactly though... Technically then if we wanted > > to keep a static cached early check of allowed channels maps for VHT > > we should be able to have a bitmap representation of the allowed IEEE > > VHT channel configurations and upon initialization / regulatory change > > update this bitmap to determine if we're allowed to use the new > > arrangement. The approach you use is also fine and while it does allow > > for flexibility to do add more technologies one should consider the > > penalty incurred at doing these computations at run time. The run time > > impact is no issue if its done just once but consider changing > > channels and how often we can do this. Consider a device now with one > > radio but two virtual devices and each one doing their own set of > > scans and two different types of HT / VHT configurations. This means > > the code you just wrote will become a real hot path -- used for > > anything that has to do with any channel change. The purpose of the > > flags are to remove that run time penalty, so if we can take into > > consideration more the nature of how we VHT channels are allowed and > > how IEEE decided to simplify the arrangements for VHT then likely > > keeping flags may make sense then. That is, not all VHT arrangements > > are possible, only a subset, and it seems fairly trivial and > > reasonable to me to do this upon regulatory change only once rather > > than at every channel change. > > > > And as for the question: "What about the future? Will we see 320 MHz > > wide channels in 2020? :)" > > > > I'm told through a shiny crystal ball: let's not expect 320 MHz channels. > > > > So I'd rather keep this simple and also due to the fact that VHT > > channels are static just try to use a bitmap for them and check for it > > at regulatory change. > > > > I agree Luis. Limiting the flags to a subset is fine with me. Hope no > more disagreements. I'm not convinced :-) Today, we have people who want to use wifi on other parts of the spectrum, like somewhere in the 800 MHz range for example. If that gets properly integrated into drivers (rather than pretending it's actually 2.4 GHz) then you may want to do something different here, and those channels would never actually have IEEE defined 80 MHz rules. Also, those definitions are arbitrary for interoperability and don't reflect regulatory rules. Yes, it may be easier today to just pretend that regulatory rules only matter for IEEE defined operation, but I'm not convinced that we really should have definitions here in the regulatory database that really only cover specific IEEE 802.11 channels. The regulatory database was designed to be at least a bit more generic and in fact we always treated it as max bandwidth etc. I think just using the 802.11 rules here would be artificially limiting the expressiveness of the regulatory database. 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
