On Sun, 2007-09-02 at 22:07 -0400, Daniel Drake wrote: > This is slightly freaky for zd1211rw and probably other USB drivers. In > most cases we can't act upon any of those filter flag changes in atomic > context. Yeah, I know, but it's running under the tx lock and I haven't seen a way to drop that (yet) > We could defer work like we do for multicast lists, but then the driver > would be lying in that it would return from configure_filter saying that > it has honoured some flags without actually having done so (yet). Yup, I saw that you do that anyway so didn't think much of it. > Will that be a problem? I'm thinking maybe not, since the flags only > affect RX and we can't determine which frames will be in the air at any > time. [as opposed to such atomicity problems that relate to TX, we can > just disable TX until the work has completed] It does matter a bit for scanning, if you have BSSID filters that affect beacons and probe responses then you would want to turn those off before transmitting the next probe response. However, when the multicast_count parameter is -1 to indicate no changes in the multicast list (and you then need to use the cached hash value in zd1211) the callback actually *can* sleep. This is a rather weird area of the patch. Splitting it up into two callbacks makes no sense, and so far I have not understood why it runs under the TX lock so haven't changed it. > > + * This callback is must be implemented. > > + */ > > Typo. Good point, thanks. Slightly updated patch at http://johannes.sipsolutions.net/patches/kernel/all/2007-09-03-08:32/021-mac80211-filter-flags.patch johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
