On Jan 30, 2008 2:38 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > Hm, true, that could happen. Does it happen in practice though? I can't > > > see why a low level driver would decide that it should have short > > > preamble or CTS protection on by default. Maybe we should just document > > > initial state? Or we can keep the initial call and remove that "don't > > > call w/o BSS" restriction instead, which seems saner. We should then > > > probably rename reset_erp_info() to reset_bss_info() though. > > > > Yes it happens in practices. I think with short slot. > > reset_bss_info() sounds good. > > Ok so let's rename reset_erp_info() to reset_bss_info() and have it > handle all the other stuff too. > > > > > 1 - change the original intention of bss_info_changed so mac80211 will > > > > be able to set low-level driver in the "init" or "configure" flows as > > > > well, not only as BSS is formed or changes > > > > 2 - maintain original intention, use "bss_info_changed" only when we > > > > want to deliver BSS configuration when we get associate or during > > > > association state, and deliver all initial configuration info through > > > > different ops > > > > > > I prefer the first option since that's essentially just a small > > > documentation change and it makes sense. We just should make sure that > > > it's called only when the device is started (through ->start()). > > > > what about reset_bss_info() ? > > Well reset_bss_info() would still call ->bss_info_changed(), no? Sounds good so far. > 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
