> > Interesting. I don't think I have an opinion right now. I wanted to be > > strict about clearing the flags so that you don't end up with a flag > > that we never get traffic for, but I can't imagine any check where you'd > > want to know "do I get traffic XY". > > The only way I think it might be useful is if it allows mac80211 to not bother > with checks that it would otherwise do, for example if mac80211 didn't want > to pass multicast packets that were not for us up to the higher stack layers > it would know that if FIF_ALLMULTI got set it needed to do some filtering but > if it wasn't set the hardware had a working multicast address filter. True, but that particular example is just more code and I don't think it'd be worth it. We also should use the flags for monitor flags, i.e. when the user requests control frames but the hw can't give them, the user should be able to query the current flags. That works the other way around too, I guess, if the user requests other-bss frames but the hw can only do that together with control frames, the user should know that. > rt2x00 ignores the changed_flags passed from mac80211 and keeps track for > itself of what filter it is applying so it will always recalculate it's own > filter based on total_flags and reconfigure the hardware if it changes. Ok. > This > does assume that mac80211 recalculates what it wants total_flags to be each > time configure_filter is called rather than just changing the value it got > back last time but that appears to be a valid assumption. Right, mac80211 does that and it has to anyway because of multiple virtual interfaces, so that assumption is indeed valid. If the driver is capable of juggling the flags properly then I'd think adding flags is fine. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
