Search Linux Wireless

Re: [PATCH 09/13] mac80211: remove hw_scan callback

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

 



Michael Wu wrote:
On Wednesday 25 April 2007 14:16, John W. Linville wrote:
On Tue, Apr 24, 2007 at 10:03:03PM -0700, James Ketrenos wrote:
(I would like to see hw_scan remain since iwlwifi uses it -- which we
hope to submit as soon as the code restructuring is complete)
I was going to mention this in response to Michael's patch, but then
I checked your current iwlwifi git tree.  There your hw_scan routine
is commented-out, so I figured you didn't want/need it anymore...?

...
Besides the fact that what hw_scan does can be done by mac80211 for all drivers,

With a penalty to battery life and an increase in the amount of time a scan takes.  There are improvements that can be made to make the software scanning faster, but at a penalty of added complexity on both the driver and the stack side -- for no *real* gain for users that have cards that can offload the scan.

the use of the hw_scan callback breaks the AP autoconfiguration code in ieee80211_sta.c due to its inadequate design.

Is it breaking it just due to the auto-configuration code not knowing when to configure things?

Calling hw_scan starts a hardware scan, but there is no way to know when the scan is completed.

That needs to be improved.

Even if that problem were addressed, I still wouldn't like it as the design of the hw_scan callback is deficient in a number of other ways and is completely inapplicable to all other hardware/firmware softmac designs that I know.

Given that there are things we can do as a result of the hw_scan that we can't do on the host without imposing greater system load and slower scan results, I really don't want to lose the ability to support hardware offloading of scanning.

Could you voice some of the "other ways" the current hw_scan callback is deficient?

I'm fine with us overhauling how hw_scan works and integrates with the stack, but an all out ban on hardware scan offload just doesn't make sense.  The host can do all RC4 and AES encrypt/decrypt too but certainly we would prefer the hardware to do that for us, right?

In the short term, I would rather we leave hw_scan in the code and have the users that currently rely on hw_scan just have to manually configure the AP selection until such time as the in-kernel-AP-selection-policy code works with hw offloaded scan.

James
-
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

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux