On Fri, 2019-03-22 at 13:40 -0700, thomas wrote: > > > OTOH, I guess if you change center_freq1 to center_freq1_khz or > > something then you compile-fail everywhere ... > > Yeah it gets ugly quick to have additional freq_khz members, > especially when doing comparisons etc. > > The kernel part was not too bad, there are only 3 structs or so to > worry about. hostap on the other hand is incredibly hairy :) We/I thought about this some more now at the wifi summit, and I think the better choice would be to just add a "u32 fractional;" part where needed. In effect, an existing u32 freq; would become u32 freq, freq_fractional; and we'd just treat the two as a 32.32 fixed point integer. Maybe even just do "u8 freq_fractional" since a 32.8 fixed point integer would be sufficient (we do need >64k MHz for WiGig, so doing 16.16 or 16.8 won't work). That would have the advantage of not requiring any changes from drivers that don't need to support it. It would also cover some of the 4.9 GHz stuff Jouni looked up - it as fractional center frequencies too (at least expressed in MHz). For userspace API I'm not really sure, maybe we should just move to KHz? Or maybe just do the same thing? On the one hand, moving to KHz would be cleaner in a sense, but on the other hand it would require doing things like checking that the KHz and MHz attributes agree if both are given, etc., so similarly adding a "fractional MHz" attribute might be nicer since we can also assume it to be 0 if not present (in fact, we could *reject* it if it's 0, thereby ensuring that it'll only ever be nonzero) johannes
