On Mon, 2013-10-14 at 16:02 +0200, Johannes Berg wrote: > On Mon, 2013-10-14 at 14:16 +0200, Dennis H Jensen wrote: > > On Mon, 2013-10-14 at 14:02 +0200, Johannes Berg wrote: > > > On Fri, 2013-10-11 at 17:45 +0200, Dennis H Jensen wrote: > > > > > > > > > + else if (chan > 196) > > > > > > + return 5000 + (chan - 15) * 5; > > > > > > > > > > Where does the +/- 15 come from? I can't find any evidence for this in > > > > > Annex E. > > > > > > > > I didn't double check Annex E. I just wanted to recover the lost > > > > frequencies that the 15 channels (182 - 196), map into 4.9 GHz. > > > > > > "Recover"? When did they work? What broke them? > > > > The commit 59eb21a6504731fc16db4cf9463065dd61093e08 moved those channels > > to 4.9 GHz but left a hole in the 5.9 Ghz range. > > But there was no +/- 15 before, so what gives? Well no :) but there also wasn't a special case for that particular channel set (182 - 196). So now, when you configure the frequency 5910, it is mapped to channel 182 which is mapped back to 4910 and nothing works, at least let the functions be the inverse of the other. In case that doesn't do it. What is needed to get channel 182 to be 5910 MHz as Annex E defines for the US and Europe? Channel to frequency mapping based on operating class? //Dennis -- 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
