- 05 Oct, 2010 8 commits
-
-
ext Anand Gadiyar authored
Patch "omap: zoom: add mmc3/wl1271 device support" in the wireless tree still uses .wires in struct omap2_hsmmc_info. .wires has now been replaced with .caps in patch "omap: mmc: extended to pass host capabilities from board file" in the OMAP tree. This causes linux-next as of 20101001 build to break as below. Fix this. CC arch/arm/mach-omap2/board-zoom-peripherals.o arch/arm/mach-omap2/board-zoom-peripherals.c:217: error: unknown field 'wires' specified in initializer make[1]: *** [arch/arm/mach-omap2/board-zoom-peripherals.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Tony Lindgren <tony@atomide.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Luciano Coelho authored
One __attribute__ ((packed)) has been accidentally introduced in commit be86cbea. This patch changes it to __packed. Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Currently a command to initialize extended radio parameter tables in the hardware is missing. Add the initialization Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
In the event of a hardware failure, reconfiguring a live connection back with the wl1271 chip does not work as expected. The chip has management features which require setting up the association from scratch to work correctly. To ensure this is done every time, in managed mode, when associated, indicate connection loss to the mac80211 before asking to reconfigure the hardware. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Tested-by: Tuomas Katila <ext-tuomas.2.katila@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Due to legacy reason, dating back to when the wl1251 and wl1271 still were a unified driver, some work-structures are initialized on hardware startup. The hardware recovery code creates a scenario in which it is possible for a workstruct to be re-initialized while the work-function itself is running, which causes a kernel WARNing and a subsequent reboot. To remedy this, move the work initialization calls to the hw allocation, which is the logically correct place for them anyway. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Tested-by: Tuomas Katila <ext-tuomas.2.katila@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Ido Yariv authored
Instead of sending one packet at a time to the firmware, try to send all available packets at once. This optimization decreases the number of transactions, which saves CPU cycles and increases network throughput. Signed-off-by: Ido Yariv <ido@wizery.com> Tested-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Ido Yariv authored
Instead of retrieving one packet at a time from the firmware, try to retrieve all available packets at once. This optimization decreases the number of transactions, which saves CPU cycles and increases network throughput. Signed-off-by: Ido Yariv <ido@wizery.com> Tested-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Ido Yariv authored
The HW supports up to 4095 bytes transfers via SPI. The SPI read & write operations do not handle larger transfers, causing the HW to stall in such cases. Fix this by fragmenting large transfers into smaller chunks, and transferring each one separately. Signed-off-by: Ido Yariv <ido@wizery.com> Tested-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
- 30 Sep, 2010 1 commit
-
-
Ohad Ben-Cohen authored
Support building wl1271-equipped boards without building the wl1271 driver itself, e.g.: CONFIG_MACH_OMAP_ZOOM3=y CONFIG_WL12XX is not set Reported-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
- 28 Sep, 2010 26 commits
-
-
Luciano Coelho authored
We are integrating wl1271 commits via a new git tree now and wl1271 development should be made on top of the new tree. Update the repository url accordingly. Cc: John W. Linville <linville@tuxdriver.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
This patch adds support for the hardware GEM cipher suite. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
This patch improves connection reliability by choosing the lowest basic rate for null-func frames (which increases their range, as the firmware does not do rate fall-back for null-func frames.) Also, increase the PSM entry retry-counter. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Tested-by: Tuomas Katila <ext-tuomas.2.katila@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Currently then dwell times for each channel in scans is set to an overly long value, and excessive number of probe-requests are transmitted on each channel (for active scans.) Based on testing, comparable results can be received with smaller dwell-time, and, with fever probe-requests - in fact, reducing the number of probe-requests to 2 seems to increase the number of found results. Configure more optimal values for per channel dwell times. Comparison for the different scan configurations (in my current office environment): dwell-time 60000 3x probe-req == ~60 results 40000 3x probe-req == ~50 results 30000 3x probe-req == ~40 results dwell-time 60000 2x probe-req == ~70 results 40000 2x probe-req == ~60 results 30000 2x probe-req == ~58 results The above are results for a cumulative 3 scan run. For individual scans, the number of results drop slightly more. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Currently, the driver does not handle a failing hardware command to scan in any way - effectively, the scan machine will jam until the driver is shut down, and future scan requests will just return -EBUSY to user space, resulting in a type of busy-loop. The same problem occurs if the firmware fails to deliver the scan completion event - add timeout for this. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
There is some probability of hardware failures, which currently go largely undetected. Attempt to recover from these failures by shutting down the hardware, and requesting mac80211 to reconfigure it. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Do this so the interface removal can be triggered from an upcoming hardware failure recovery mechanism. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
The work cancelling has had several hazards, ranging from potentially executing work after the driver is in OFF state, to executing work after the driver and relevant memory structures are already removed. Fix these. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
The current scan implementation can jam, if the scan request ends up containing no work. This can especially happen if there is a scan request with only 11a band channels for HW that does not support 11a. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
The WMM queue default configuration was incorrect, and caused uapsd mode problems (among possible others.) Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Incorrect TID was configured for TX frames. This resulted in incorrect queues to be used for classes in transmission. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
This patch always enables 11a band towards the mac80211, but prevents scanning (and hence the usage of) 11a band channels if the chipset does not support it. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
This patch reduces the rate of the null-func used to enter PSM on the last retry as precaution. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Instead of hardcoding 11a support, enable/disable driver support based on the dual-mode-select parameter in the nvs-file general paramters. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
The function is not used anywhere. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
The current order causes driver releasing to fail in various ways, and causes possible instability. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
It's not used anywhere. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
This removes a fixme. Also, it removes a redundant setting of the wake-up conditions when exiting power save mode, which should improve performance. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Remove outdated FIXME's from the code. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
The mac80211 inserts channels into a scan request in the same order the driver registers them. Use this fact to optimize scan by ordering the channels so that adjacent channels don't get scanned consecutively. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Luciano Coelho authored
When we get no SSIDs in the scan request, we should force a passive scan in all channels. This patch adds code to force the passive scan flag to be set in that case. Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
-
Luciano Coelho authored
This code was a leftover of the previous scanning mechanism. The if is totally unnecessary, since both branches do the same thing. Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Reviewed-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
-
Juuso Oikarinen authored
In the scan state machine, the wl1271_mutex is unlocked first then relocked, and then the scan state variables are modified. This makes it possible for ieee80211_scan_complete to be called twice in some scenarios, as the scan completion event from the firmware may be processed while the mutex is unlocked. To fix the issue, move the ieee80211_scan_complete call last in the function. This is generally safer, but there still may be issues is functions calling the scan state machine rely on states checked before the unlocking of the global mutex. (forward ported from 2.6.32 -- this is not strictly needed anymore, because the mutex doesn't need to be unlocked anymore, but I'm applying this change anyway, so that the call to ieee80211_scan_complete is in the same place) Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Add a trigger to net_device changes to monitor for oper_state changes in order to be able to inform the firmware when association is fully complete (including the EAP negotiation.) Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Juuso Oikarinen authored
Implement the command function to send CMD_SET_STA_STATE to the firmware. This is used to indicate that association (and the related EAP negotiation) are complete. This is used to tune WLAN-BT coexistense priority towards BT, improving BT A2DP and SCO performance. Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com> Reviewed-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
-
Luciano Coelho authored
As of Rev. 6.1.0.0.335, the ACX_SET_SMART_REFLEX_DEBUG command is deprecated. This patch removes it from the wl1271 driver (it wasn't used anyway). Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Reviewed-by: Saravanan Dhanabal <ext-saravanan.dhanabal@nokia.com>
-
- 27 Sep, 2010 5 commits
-
-
Rajkumar Manoharan authored
The following commit removed splitmic. But forgot to add ATH_CRYPT_CAP_MIC_COMBINED flag for HTC drivers which causes TKIP to fail. Author: Bruno Randolf <br1@einfach.org> Date: Wed Sep 8 16:04:54 2010 +0900 ath/ath9k: Replace common->splitmic with a flag Replace common->splitmic with ATH_CRYPT_CAP_MIC_COMBINED flag. Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
commit 8c0c709e Author: Johannes Berg <johannes@sipsolutions.net> Date: Wed Nov 25 17:46:15 2009 +0100 mac80211: move cmntr flag out of rx flags moved the CMNTR flag into the skb RX flags for some aggregation cleanups, but this was wrong since the optimisation this flag tried to make requires that it is kept across the processing of multiple interfaces -- which isn't true for flags in the skb. The patch not only broke the optimisation, it also introduced a bug: under some (common!) circumstances the flag will be set on an already freed skb! However, investigating this in more detail, I found that most of the flags that we set should be per packet, _except_ for this one, due to a-MPDU processing. Additionally, the flags used for processing (currently just this one) need to be reset before processing a new packet. Since we haven't actually seen bugs reported as a result of the wrong flags handling (which is not too surprising -- the only real bug case I can come up with is an a-MSDU contained in an a-MPDU), I'll make a different fix for rc. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Even if the reorder timeout timer fires while scanning, the frames weren't received during scanning and therefore shouldn't be dropped. To implement this, changes to the passive scan RX handler simplify understanding it, because it currently checks HW_SCANNING independently of a packet's in-scan receive status (which doesn't make a big difference, since scan_rx() will only pick up probe responses and beacons, which can't be aggregated.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
If a station was found, then we'll have exited the function already, so it is not necessary to have a variable keeping track of it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
There are now four instances of vaguely the same code that does packet preparation, checking for MMIC errors and reporting them, and then invoking packet processing. Consolidate all of these. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-