On Thu, Feb 10, 2011 at 03:48:57PM +0800, æææ wrote:
> Yes, that flush can work well, but before drv_flush in
> ieee80211_start_sw_scan have no queue stop actions.
> Below are corresponding code:
> static int ieee80211_start_sw_scan(struct ieee80211_local *local)
> {
> /*
> * Hardware/driver doesn't support hw_scan, so use software
> * scanning instead. First send a nullfunc frame with power save
> * bit on so that AP will buffer the frames for us while we are not
> * listening, then send probe requests to each channel and wait for
> * the responses. After all channels are scanned, tune back to the
> * original channel and send a nullfunc frame with power save bit
> * off to trigger the AP to send us all the buffered frames.
> *
> * Note that while local->sw_scanning is true everything else but
> * nullfunc frames and probe requests will be dropped in
> * ieee80211_tx_h_check_assoc().
> */
> drv_sw_scan_start(local);
>
> ieee80211_offchannel_stop_beaconing(local);
>
> local->leave_oper_channel_time = 0;
> local->next_scan_state = SCAN_DECISION;
> local->scan_channel_idx = 0;
>
> drv_flush(local, false);
I looked at wireless-testing tree where code was currently
changed by b23b025fe246f3acc2988eb6d400df34c27cb8ae
"mac80211: Optimize scans on current operating channel."
We stop queues and flush only when leaving operating channel in
ieee80211_scan_state_leave_oper_channel(), what seems to be correct.
Regarding linux-2.6 tree. I think you have right and we have bug
in mac80211, because we do not stop queues before flush in
ieee80211_offchannel_stop_beaconing() when working in STA mode.
Also comment in above function seems to be wrong.
I'm not sure what to do with that, maybe Johannes will
have some insight?
Anyway, chaoming_li, could you clone current wireless-testing
tree and see how things work there?
--
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
