aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/iwlwifi
Commit message (Collapse)AuthorAge
* Merge branch 'master' of ↵David S. Miller2009-08-12
|\ | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: arch/microblaze/include/asm/socket.h
| * iwlagn: do not send key clear commands when rfkill enabledReinette Chatre2009-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do all key clearing except sending sommands to device when rfkill enabled. When rfkill enabled the interface is brought down and will be brought back up correctly after rfkill is enabled again. Same change is not needed for iwl3945 as it ignores return code when sending key clearing command to device. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13742 Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * drivers/net/wireless/iwlwifi: introduce missing kfreeJulia Lawall2009-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move orthogonal error handling code up before a kzalloc, so that it doesn't have to free the allocated data. The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return \(0\|<+...x...+>\|ptr\); | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: fix regression on beacon world roaming featureLuis R. Rodriguez2009-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A regression was added through patch a4ed90d6: "cfg80211: respect API on orig_flags on channel for beacon hint" We did indeed respect _orig flags but the intention was not clearly stated in the commit log. This patch fixes firmware issues picked up by iwlwifi when we lift passive scan of beaconing restrictions on channels its EEPROM has been configured to always enable. By doing so though we also disallowed beacon hints on devices registering their wiphy with custom world regulatory domains enabled, this happens to be currently ath5k, ath9k and ar9170. The passive scan and beacon restrictions on those devices would never be lifted even if we did find a beacon and the hardware did support such enhancements when world roaming. Since Johannes indicates iwlwifi firmware cannot be changed to allow beacon hinting we set up a flag now to specifically allow drivers to disable beacon hints for devices which cannot use them. We enable the flag on iwlwifi to disable beacon hints and by default enable it for all other drivers. It should be noted beacon hints lift passive scan flags and beacon restrictions when we receive a beacon from an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz band. We don't bother with channels 1-11 as those channels are allowed world wide. This should fix world roaming for ath5k, ath9k and ar9170, thereby improving scan time when we receive the first beacon from any AP, and also enabling beaconing operation (AP/IBSS/Mesh) on cards which would otherwise not be allowed to do so. Drivers not using custom regulatory stuff (wiphy_apply_custom_regulatory()) were not affected by this as the orig_flags for the channels would have been cleared upon wiphy registration. I tested this with a world roaming ath5k card. Cc: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: remove duplicated version info from sysfsJay Sternberg2009-08-04
| | | | | | | | | | | | | | | | | | | | | | version info in sysfs had been determined to be unnecessary as it is already provided in syslog info. nvm version is added to syslog version info as a debug level message to provide all info that was in the version sysfs data. Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: remove deprecated 6000 series adaptersWey-Yi Guy2009-08-04
| | | | | | | | | | | | | | | | | | Remove the support for deprecated devices. These devices are engineering samples and no longer supported by the uCode. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: Distinguish power amplifier for 6000 seriesWey-Yi Guy2009-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For 6x00 2x2 NIC, two types of Power Amplifier are available. In order for uCode to apply correct tx power, driver needs to program the CSR_GP_DRIVER_REG register and let uCode know the type of PA. If driver do not program CSR_GP_DRIVER_REG register (default to 0), then it is uCode's decision for tx power 2x2 Hybrid card: use both internal and external PA 2x2 IPA(Internal Power Amplifier) card: internal PA only Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: clear iwl_cmd_meta structure before useDaniel C Halperin2009-08-04
| | | | | | | | | | | | | | | | | | Resolve an issue in which out-dated fields in iwl_cmd_meta could be used for later hardware commands. Signed-off-by: Daniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: remove usage of orig_flagsLuis R. Rodriguez2009-08-04
| | | | | | | | | | | | | | | | | | | | This is a private flag, internal to cfg80211. cfg80211 will set orig_* stuff internally upon wiphy registration, drivers do not need to muck with it. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Acked-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: don't export symbols not needed in other modulesJohannes Berg2009-08-04
| | | | | | | | | | | | | | | | | | Even with the split into iwlcore/agn/3945 not all symbols that cross file boundaries are needed in other modules, a few are only used within iwlcore, for example. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | Merge branch 'master' of ↵David S. Miller2009-07-30
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
| * | iwlwifi: debugFs to enable/disable HT40 supportWey-Yi Guy2009-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add debugfs file to enable/disable HT40(40MHz) channel support. By default, 40MHz is supported if AP can support the function. By echo "1" to "disable_ht40" file, iwlwifi driver will disable the 40MHz support and only allow 20MHz channel. Because the information exchange happen during association time, so enable/disable ht40 channel only can be performed when it is not associated with AP. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlagn: fix sparse warning when compiling without debugReinette Chatre2009-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C [M] drivers/net/wireless/iwlwifi/iwl-core.o drivers/net/wireless/iwlwifi/iwl-core.c:1341: warning: ‘iwl_dump_nic_error_log’ defined but not used Reported-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlagn: fix null pointer access during ucode load on 1000Reinette Chatre2009-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit "iwlwifi: Handle new firmware file with ucode build number in header" introduced new ucode header parsing routines, but neglected to initialize these routines for 1000. The system thus goes into infinite loop trying to load ucode, failing every time with a null pointer exception as it tries to parse the header. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: fix LED config optionPavel Machek2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | IWLWIFI_LEDS option should certainly have help comment, and should default to y. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: Name fix for MPDU density for TX aggregationWey-Yi Guy2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix incorrect name for HT MPDU Density. default set to 4 uSec Reported-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: print packet contents in error caseReinette Chatre2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | This data is more useful to debugging that the receive buffer contents. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: remove command callback return valueJohannes Berg2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No existing callbacks use anything other than the return value 1, which means that the caller should free the reply skb, so it seems safer in terms of not introducing memory leaks to simply remove the return value and let the caller always free the skb. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: fix up command sendingJohannes Berg2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current command sending in iwlwifi is a bit of a mess: 1) there is a struct, iwl_cmd, that contains both driver and device data in a single packed structure -- this is very confusing 2) the on-stack data and the command metadata share a structure by embedding the latter in the former, which is also rather confusing because it leads to weird unions and similarly odd constructs 3) each txq always has enough space for 256 commands, even if only 32 end up being used This patch fixes these things: 1) rename iwl_cmd to iwl_device_cmd and keep track of command metadata and device command separately, in two arrays in each tx queue 2) remove the 'meta' member from iwl_host_cmd and only put in the required members 3) allocate the cmd/meta arrays separately instead of embedding them into the txq structure Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: Thermal Throttling debugfs functionWey-Yi Guy2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add debugfs function to display current thermal throttling status for both Legacy and Advance Thermal Throttling Management Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: Thermal Throttling Management - part 2Wey-Yi Guy2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part 2 of Thermal Throttling Management - Thermal Throttling feature is used to put NIC into low power state when driver detect the Radio temperature reach pre-defined threshold Two Thermal Throttling Management Methods; this patch introduce the Advance Thermal Throttling: TI-0: system power index, no tx/rx restriction, HT enabled TI-1: power index 5, 1 spatial stream Tx, multiple spatial stream Rx, HT enabled TI-2: power index 5: 1 spatial stream Tx, 1 spatial stream Rx, HT disabled TI-CT-KILL: power index 5, no Tx, no Rx, HT disabled For advance Thermal Throttling, CT_KILL_ENTER threshold and CT_KILL_EXIT threshold are different; uCode will not stay awake until reach CT_KILL_EXIT threshold. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: Thermal Throttling Management - Part 1Wey-Yi Guy2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Part 1 of Thermal Throttling Management - Thermal Throttling feature is used to put NIC into low power state when driver detect the Radio temperature reach pre-defined threshold Two Thermal Throttling Management Methods; this patch introduce the Legacy Thermal Management: IWL_TI_0: normal temperature, system power state IWL_TI_1: high temperature detect, low power state IWL_TI_2: higher temperature detected, lower power state IWL_TI_CT_KILL: critical temperature detected, lowest power state Once get into CT_KILL state, uCode go into sleep, driver will stop all the active queues, then move to IWL_TI_CT_KILL state; also set up 5 seconds timer to toggle CSR flag, uCode wake up upon CSR flag change, then measure the temperature. If temperature is above CT_KILL exit threshold, uCode go backto sleep; if temperature is below CT_KILL exit threshold, uCode send Card State Notification response with appropriate CT_KILL status flag, and uCode remain awake, Driver receive Card State Notification Response and update the card temperature to the CT_KILL exit threshold. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: critical temperature enter/exit conditionWey-Yi Guy2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If advance thermal throttling is used the driver need to pass both "enter" and "exit" temperature to uCode. Using different critical temperature threshold for legacy and advance thermal throttling management based on the type of thermal throttling method is used except 1000. For 1000, it use advance thermal throttling critical temperature threshold, but with legacy thermal management implementation until ucode has the necessary implementations in place. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | iwlwifi: revert to active table when rate is not validWey-Yi Guy2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When performing rate scaling, if detected that the new rate index is invalid, clear the search_better_tbl flag so it will not be stuck in the loop. Since the search table is already set up in uCode, we need to empty out the the search table; revert back to the "active" rate and throughput info. Also pass the "active" table setup to uCode to make sure the rate scale is functioning correctly. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | | Merge branch 'master' of ↵David S. Miller2009-07-30
|\ \ \ | |/ / |/| / | |/ | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/iwlwifi/iwl-3945.h drivers/net/wireless/iwlwifi/iwl-tx.c drivers/net/wireless/iwlwifi/iwl3945-base.c
| * iwlwifi: Read outside array boundsRoel Kluin2009-07-27
| | | | | | | | | | | | | | | | tid is bounded (above) by the size of default_tid_to_tx_fifo (17 elements), but the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * iwlagn: fix minimum number of queues settingreinette chatre2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to provide a reasonable minimum that will result in a working setup if used. Set minimum to be 10 to provide for 4 standard TX queues + 1 command queue + 2 (unused) HCCA queues + 4 HT queues (one per AC). We allow the user to change the number of queues used via a module parameter and use this minimum value to check if it is valid. Without this patch a user can select a value for the number of queues that will result in a failing setup. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * iwlwifi: fix TX queue raceJohannes Berg2009-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I had a problem on 4965 hardware (well, probably other hardware too, but others don't survive my stress testing right now, unfortunately) where the driver was sending invalid commands to the device, but no such thing could be seen from the driver's point of view. I could reproduce this fairly easily by sending multiple TCP streams with iperf on different TIDs, though sometimes a single iperf stream was sufficient. It even happened with a single core, but I have forced preemption turned on. The culprit was a queue overrun, where we advanced the queue's write pointer over the read pointer. After careful analysis I've come to the conclusion that the cause is a race condition between iwlwifi and mac80211. mac80211, of course, checks whether the queue is stopped, before transmitting a frame. This effectively looks like this: lock(queues) if (stopped(queue)) { unlock(queues) return busy; } unlock(queues) ... <-- this place will be important there is some more code here drv_tx(frame) The driver, on the other hand, can stop and start queues, which does lock(queues) mark_running/stopped(queue) unlock(queues) [if marked running: wake up tasklet to send pending frames] Now, however, once the driver starts the queue, mac80211 can see that and end up at the marked place above, at which point for some reason the driver seems to stop the queue again (I don't understand that) and then we end up transmitting while the queue is actually full. Now, this shouldn't actually matter much, but for some reason I've seen it happen multiple times in a row and the queue actually overflows, at which point the queue bites itself in the tail and things go completely wrong. This patch fixes this by just dropping the packet should this have happened, and making the lock in iwlwifi cover everything so iwlwifi can't race against itself (dropping the lock there might make it more likely, but it did seem to happen without that too). Since we can't hold the lock across drv_tx() above, I see no way to fix this in mac80211, but I also don't understand why I haven't seen this before -- maybe I just never stress tested it this badly. With this patch, the device has survived many minutes of simultanously sending two iperf streams on different TIDs with combined throughput of about 60 Mbps. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: change iwl_enable/disable_interrupts to "inline"Wey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | iwl_enable_interrupts is being called inside the interrupt, change from function call to inline Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: inform user about rfkill state changesReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | | | | | rfkill state changes are mostly available through debug messages. These are significant enough to always make user aware of so we turn them into warnings. Also insert a missing newline in some rfkill related debug message. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: clarify hardware error messageReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | When a hardware error is detected we need to be clear about that and not create impression that the microcode is able to deal with it. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: make debug level more user friendlyReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Deprecate the "debug50" module parameter used to obtain 5000 series and up debugging. Replace it with "debug" module parameter to match with original driver and be consistent between them. The "debug50" module parameter can still be used, except that the module parameter is not writable in keeping with its previous state. We currently just mark it as "deprecated" and do not have it in the feature-removal-schedule. Some more cleanup of module parameters needs to be done and can then be entered together. * Only make "debug" module parameters visible if the driver is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate a lot of confusion where users think they have set debug flags but yet cannot see any debug output. * Make module parameters writable. This eliminates the need for the "debug_level" sysfs file, which can now also be deprecated and added to feature-removal-schedule. This file is in significant use though with many iwlwifi documents and text referring users to it. We can thus not take its removal lightly and keep it around. With iwlcore shared between iwlagn and iwl3945 we really do not need debug module parameters for each but can instead have one debug module parameter for the iwlcore module. The same issue is here as with the sysfs file - a lot of iwlwifi documentation and text (like bug reports) rely on iwlagn and iwl3945 having this module parameter, so changing this to a module parameter of iwlcore will have significant impact and we do not do this for that reason. One consequence of this patch is that if a user is running a system with both 3945 and later hardware then the setting of the one module parameter will affect the value of the other. The likelihood of this seems low - and even if this setup is present it does not seem like an issue for both modules to run with the same debug level. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: uCode Alive notification with timeoutWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Wait for REPLY_ALIVE notification from init and runtime uCode. based on the type of REPLY_ALIVE, different status bit will be set to wake up the queue: STATUS_INIT_UCODE_ALIVE for init uCode STATUS_RT_UCODE_ALIVE for runtime uCode. If timeout, attempt to download the failing uCode image again. This can only be done for the init ucode images of all iwlagn devices and the runtime ucode image of the 5000 series and up. If there is a problem with the 4965 runtime ucode coming up we restart the interface and thus trigger a new download of the init ucode also. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: update 1000 series API version to match firmwareJay Sternberg2009-07-24
| | | | | | | | | | | | | | | | firmware file now contains build number so API needs to be updated. Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: checking unknown HW typeWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | | | When deciding NVM type, if the HW type is unknown, report error and exit with -ENOENT. This check should prevent incorrect behavior by assuming the wrong NVM type. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: Led blinking counting both tx and rxWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | For controlling led blinking, counting both tx and rx data traffic; this will be able to handle traffic in either direction Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: add led debugfs functionWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | Adding debugfs file to show current led blinking rate /sys/kernel/debug/ieee80211/phy0/iwlagn/data/led Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlagn: do not send key clear commands when rfkill enabledReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do all key clearing except sending sommands to device when rfkill enabled. When rfkill enabled the interface is brought down and will be brought back up correctly after rfkill is enabled again. Same change is not needed for iwl3945 as it ignores return code when sending key clearing command to device. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13742 Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: make led functions genericWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | Led functions are generic for all the devices except 3945, so remove the reference to 4965 Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: Handle new firmware file with ucode build number in headerJay Sternberg2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding new API version to account for change to ucode file format. New header includes the build number of the ucode. This build number is the SVN revision thus allowing for exact correlation to the code that generated it. The header adds the build number so that older ucode images can also be enhanced to include the build in the future. some cleanup in iwl_read_ucode needed to ensure old header not used and reduce unnecessary references through pointer with the data is already in heap variable. Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: fix rx signal quality reporting in dmesgWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | Fix quality incorrectly reported as signal strength value. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlagn: modify digital SVR for 1000Wey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | | | | | On 1000, there are two Switching Voltage Regulators (SVR). The first one apply digital voltage level (1.32V) for PCIe block and core. We need to use this regulator to solve a stability issue related to noisy DC2DC line in the silicon. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | mac80211: add helper for management / no-ack frame rate decisionLuis R. Rodriguez2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All current rate control algorithms agree to send management and no-ack frames at the lowest rate. They also agree to do this when sta and the private rate control data is NULL. We add a hlper to mac80211 for this and simplify the rate control algorithm code. Developers wishing to make enhancements to rate control algorithms are for broadcast/multicast can opt to not use this in their gate_rate() mac80211 callback. Cc: Zhu Yi <yi.zhu@intel.com> Acked-by: Reinette Chatre <reinette.chatre@intel.com> Cc: ipw3945-devel@lists.sourceforge.net Cc: Gabor Juhos <juhosg@openwrt.org> Acked-by: Felix Fietkau <nbd@openwrt.org> Cc: Derek Smithies <derek@indranet.co.nz> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: use ieee80211_is_data(fc)Luis R. Rodriguez2009-07-24
| | | | | | | | | | | | | | | | | | | | iwl-agn-rs.c already uses this. Cc: Zhu Yi <yi.zhu@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Cc: ipw3945-devel@lists.sourceforge.net Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: remove rs_get_rate workaroundLuis R. Rodriguez2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | This removes the work around implemented for transmitting on an unsupported band on iwlwifi. This was added via the patch: 8e1856e82cb8f541e925738bebfbc473420cda68: iwlwifi: fix rs_get_rate WARN_ON() Cc: Mohamed Abbas <mohamed.abbas@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: make some logging functions static/unexportJohannes Berg2009-07-24
| | | | | | | | | | | | | | | | | | iwl_dump_nic_error_log can be static and iwl_dump_nic_event_log doesn't need to be exported. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlagn: fix minimum number of queues settingReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to provide a reasonable minimum that will result in a working setup if used. Set minimum to be 10 to provide for 4 standard TX queues + 1 command queue + 2 (unused) HCCA queues + 4 HT queues (one per AC). We allow the user to change the number of queues used via a module parameter and use this minimum value to check if it is valid. Without this patch a user can select a value for the number of queues that will result in a failing setup. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwl3945: cleanup number of queues settingsReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | * Rename maximum number of queue (TFD_QUEUE_MAX) to IWL39_NUM_QUEUES to be consistent with rest of iwlwifi. * Remove unused defines. * Fix loops that iterate over number of TX queues to stop when maximum is reached (currently it is maximum + 1). * Remove queues_num module parameter as it is not used. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: fix permissions on debugfs filesReinette Chatre2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | debugfs files are created with 644 permissions which gives everybody read access. This presents a security issue if a user opens the file and holds it open at the time the driver removes the file. At this point invalid memory will be accessed. Fix this by only allowing root to read debugfs files. Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | iwlwifi: move show_qos to debugfsWey-Yi Guy2009-07-24
| | | | | | | | | | | | | | | | | | | | | | | | This move the show_qos file from sysfs to debugfs because the "one value per file" sysfs rule. The file is located in /sys/kernel/debug/ieee80211/phy0/iwlagn/data Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>