On Fri, 2012-12-14 at 11:35 +0100, Johannes Berg wrote: > On Thu, 2012-12-13 at 14:11 -0800, Luis R. Rodriguez wrote: > > On Thu, Dec 6, 2012 at 8:47 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > > > > > The channel bandwidth handling isn't really quite right, > > > it assumes that a 40 MHz channel is really two 20 MHz > > > channels, which isn't strictly true. This is the way the > > > regulatory database handling is defined right now though > > > so remove the logic to handle other channel widths. > > > I didn't see the replacement work in place but I assume its coming > > through RFCs or already posted so: > > I'm not planning to replace this (dead) code, at least not right now. > > All current users of the function pass 0, which assumes 20 MHz, so > basically all I'm doing is remove this unused argument and code > associated with it. > > Now, due to the way the regulatory database works, the argument was > never actually useful unless somebody wanted to support 5/10 MHz > channels and had a regulatory domain that only allowed those (and didn't > allow 20 MHz!) > > For wider bandwidths, the way the regulatory db is currently defined (by > the way it's always been handled) is that all the secondary channels > must exist and allow the bandwidth, but that's a little different so I > also don't see any way this argument would currently be useful. And "currently" really means "until an entirely new regulatory framework with different rule interpretation is defined". 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
