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

[James Ketrenos <jketreno@linux.intel.com>]

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