Hi Sean, Issuing WLC_SCAN ioctl triggers scan in FW. Once FW finishes scan, driver will get SCAN_COMPLETE event from FW. In case of successful scan, driver will get SCAN_COMPLETE event with success message, then driver will inform all the bss found during the scan to cfg80211 & then call cfg80211_scan_done() with scan_abort set to false. In case of scan abort by FW(This can happen if the link to the associated AP is broken or FW got a connect request from the driver while scanning etc.. ), driver will get SCAN_COMPLETE event with failure message, then driver has to inform cfg80211 regarding the aborted scan(this got fixed recently). As requested by Grant, I am attaching all patches which are currently under review. I hope this patch might fix your issue. Please let me know if you still have the issue with steps to reproduce. Regards, Sukesh. -----Original Message----- From: seanpaul@xxxxxxxxxx [mailto:seanpaul@xxxxxxxxxx] On Behalf Of Sean Paul Sent: Thursday, May 12, 2011 2:18 PM To: Sukesh Srikakula Cc: Arend Van Spriel; devel@xxxxxxxxxxxxxxxxxxxxxx; grundler@xxxxxxxxxxxx; bryeung@xxxxxxxxxxxx; Sandeep Kumar; Venkat Rao Subject: Re: [PATCH] brcm80211: Allow scans after scanning for specific ssid On Thu, May 12, 2011 at 8:15 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > On Thu, May 12, 2011 at 2:28 AM, Sukesh Srikakula <sukeshs@xxxxxxxxxxxx> wrote: >> Hi Sean, >> >> Your fix looks to be hacky. With your fix, brcm driver will always report success for cfg80211_scan_done. >> But, there are some occasions where scan may be aborted by FW, which needs to be reported to cfg80211. > > There are cases where wl_dev_ioctl returns 0, but the scan was > aborted? That seems incorrect to me. If we > can't trust the error code coming out of the ioctl call, is there > another way to differentiate this case? > Sukesh: Any info on this? It would be great if you could provide me with a means to tell if the FW aborted instead of completed. >> >> In my view, first we need to debug why iscan is unable to send cfg80211_scan_done notification. > > In the case I'm covering here, iscan isn't called (iscan_req == > false). In fact, the wl_do_iscan path works > just fine for me. > >> Recently, we fixed some issues related to scan. Those fixes might help here. Currently they are under >> review. Will let you know once they reached the staging tree. > > Thanks for the update! Like Grant said, the driver is not functional for me right now. With this patch, it is functional. I'd love to try your patches to see if they solve my problem, and if not, help debug it in a way that is not hacky. I've got 20 boards without wireless right now, and it would be great to fix that ASAP. Thanks, Sean
Attachment:
patch_to_google
Description: patch_to_google
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
