On Tue, 2009-12-01 at 11:18 -0800, Luis R. Rodriguez wrote: > >> That looks like a hack to me. > >> > >> Maybe it should be treated like other CRDA flags? In fact, you can find > >> this in dbparse.py in the wireless-regdb sources: > >> > >> # hole at bit 9. FIXME: Where is NO-HT40 defined? > >> 'NO-HT40': 1<<10, > >> > >> However, there are no other references to NO-HT40 in the wireless-regdb > >> or CRDA sources. I assume it's not implemented. > > > > It's not a regulatory requirement, it's a coexistence requirement. > > To extend this text a little more, me and Johannes had reviewed usage > of a NO-HT40 flag for regulatory purposes a while back. It was used > mainly on the old Atheros HAL regulatory code and upon a lot of review > even with our own regulatory folks determined that in fact there was > no specific rules about disallowing 40 MHz, but that when this was > disallowed it can be implied by the frequency range not fitting a 40 > MHz channel. This is currently computed dynamically now on cfg80211 > and its results are outputed through the file: > > /sys/kernel/debug/ieee80211/phy0/ht40allow_map OK, good to know. Anyway, I think that using module parameters for any configuration creates a bad precedent. Disabling HT40 in the 2.4GHz band is a "fine tuning" compared to other settings. But there may be many other such "knobs" (e.g. ACK timeout), and if they all are controlled by mac80211 parameters, it would be a maintenance nightmare. If module parameters are discourages for the drivers, mac80211 should be held to the same standard. -- Regards, Pavel Roskin -- 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
