Re: [PATCH 08/10] mac80211: Support on-channel scan option.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 04/11/2012 08:45 PM, Johannes Berg wrote:
On Wed, 2012-04-11 at 10:52 -0700, greearb@xxxxxxxxxxxxxxx wrote:

  static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
  				  struct cfg80211_scan_request *req)
@@ -438,10 +461,43 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
  	local->scan_req = req;
  	local->scan_sdata = sdata;

-	if (local->ops->hw_scan)
+	if (local->ops->hw_scan) {
  		__set_bit(SCAN_HW_SCANNING,&local->scanning);
-	else
-		__set_bit(SCAN_SW_SCANNING,&local->scanning);
+	} else {
+		/* If we are scanning only on the current channel, then
+		 * we do not need to stop normal activities
+		 */
+		if ((req->n_channels == 1)&&
+		    (req->channels[0]->center_freq ==
+		     local->hw.conf.channel->center_freq)) {

how about "else if {", then the indentation isn't so deep and you can
have much nicer code in the entire block :)

+			unsigned long next_delay;

please add a blank line after variable declarations.

+		}
+		else {

please read the coding style documentation

@@ -672,6 +704,12 @@ void ieee80211_scan_work(struct work_struct *work)

  	sdata = local->scan_sdata;

+	/* When scanning on-channel, the first-callback means completeed. */

typo "completed"

Ok, will fix all of that.


+	if (test_bit(SCAN_ONCHANNEL_SCANNING,&local->scanning)) {
+		aborted = test_and_clear_bit(SCAN_ABORTED,&local->scanning);
+		goto out_complete;
+	}

how does the onchannel bit get cleared?

__ieee80211_scan_completed sets local->scanning to 0, and it
will WARN_ON if local->scanning is NOT zero when entering
the method, so I don't think I should clear it earlier.

Shouldn't you be calling pre/post scan hooks?

Probably so...I'll add that.  Doesn't look like ath9k uses
it, but maybe some other NIC does need it.

I'm a bit divided over this. On the one hand, it seems like a mildly
useful optimisation, on the other though it adds a bunch of complexity
for multi-channel we've been thinking about... Not that we want to
support multi-channel with SW scan anyway, but still.

It's just an optimization...maybe just add a check and do a regular scan
if multi-channel is active if it's difficult to just make it work with
multi-channel?

Thanks,
Ben


johannes


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux Kernel Discussion]     [Ethernet Bridging]     [Linux Wireless Networking]     [Linux Bluetooth Networking]     [Linux Networking Users]     [VLAN]     [Git]     [IETF Annouce]     [Linux Assembly]     [Security]     [Bugtraq]     [Photo]     [Singles Social Networking]     [Yosemite Information]     [MIPS Linux]     [ARM Linux Kernel]     [ARM Linux]     [Linux Virtualization]     [Linux Security]     [Linux IDE]     [Linux RAID]     [Linux SCSI]     [Free Dating]

Add to Google Powered by Linux