- 10 Apr, 2012 17 commits
-
-
Johannes Berg authored
This field is never set to anything non-zero in mac80211, so we should be able to remove it. Unfortunately though, the iwlwifi and iwlegacy drivers use it for their internal TX status processing (which shouldn't be using the rate control API to start with), so add a new field "status.antenna" for them, at least for now. In the future, I plan to use the new field to hold the hardware queue, while the SKB's queue mapping holds the AC. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Devices that have internal rate control need to be notified when the bandwidth or SMPS state changes just like external rate control algorithms get a notification now. Add this notification and clarify the change bits while at it, the HT_CHANGED bit really meant only bandwidth changed. Signed-off-by:
-
Johannes Berg authored
We currently stop the queue when changing the rate control between 20/40 MHz in the BSS. This seems to have been necessary when we actually changed the channel, but now that we just update the station it doesn't seem right any more. Remove it. Signed-off-by:
-
Johannes Berg authored
The channel type argument to the rate_update() callback isn't really the correct way to give the rate control algorithm about the desired RX bandwidth of the peer. Remove this argument, and instead update the STA capabilities with 20/40 appropriately. The SMPS update done by this callback works in the same way, so this makes the callback cleaner. Signed-off-by:
-
Johannes Berg authored
Changing the channel type during operation is confusing to some drivers and will be hard to handle in multi-channel scenarios. Instead of changing the channel, set it to the right HT channel before authenticating/associating and don't change it -- just update the 20/40 MHz restrictions in rate control as needed when changed by the AP. This also fixes a problem that Paul missed in his fix for the "regulatory makes us deaf" issue -- when we couldn't use 40 MHz we still associated saying we were using 40 MHz, which could in similarly broken APs make us never even connect successfully. Signed-off-by:
-
Johannes Berg authored
Use the AC constants instead of hard-coding the numbers with comments. Signed-off-by:
-
Johannes Berg authored
This is a trivial wrapper function, inline it. Signed-off-by:
-
Johannes Berg authored
There's no reason for it to not be static. Signed-off-by:
-
Johannes Berg authored
Clean up the code formatting and also replace the constant 0 by IEEE80211_AC_VO. Signed-off-by:
-
Johannes Berg authored
Fix bad indentation & pointless if nesting. Signed-off-by:
-
Johannes Berg authored
IEEE80211_MAX_QUEUES is an internal mac80211 value, it is not guaranteed to be always 4. The firmware API in mwifiex almost certainly doesn't care about mac80211 changing though, so mwifiex shouldn't use this value. Maybe it should use IEEE80211_NUM_ACS instead and that is what I'm doing here as at least that value will probably never change, but maybe it should have its own define instead. Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Johannes Berg authored
Not all devices are really capable of implementing remain-on-channel, even if it is implemented in SW, as they can't necessarily deal with channel changes while associated. Remove the WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL and add it only if either the driver has remain_on_channel implemented in the driver/device. Also add it to all drivers that advertise P2P right now since those definitely have to have it working. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Larry Finger authored
In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These are caused by the DMA buffers used for beacons never being unmapped. This bug was also reported at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618Reported-and-Tested-by:
Da Xue <da@lessconfused.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
Joe Perches authored
Prefix dmesg output with "iwlwifi: " by adding #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Oliver Hartkopp authored
In the case of disabled CONFIG_IWLWIFI_DEBUGFS option the compiler complains about the unused variable 'img'. Fix this by moving the 'img' definition. Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Acked-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Joe Perches authored
Macros can be converted to functions to reduce overall object size. Convert the ATH5K_PRINTK macro to use _ath5k_printk. Allyesconfig size is reduced ~10% $ size drivers/net/wireless/ath/ath5k/built-in.o* text data bss dec hex filename 211557 2032 40672 254261 3e135 drivers/net/wireless/ath/ath5k/built-in.o.new 235412 2032 47296 284740 45844 drivers/net/wireless/ath/ath5k/built-in.o.old Signed-off-by:
-
Joe Perches authored
Use a more current logging style. Make sure all output is prefixed appropriately. Signed-off-by:
-
- 09 Apr, 2012 23 commits
-
-
Don Fry authored
Move the POWER_PMI to the op_mode where it is changed. The trans needs to check it frequently, so shadow the status in the trans and update it in trans when it infrequently changes. Signed-off-by:
Don Fry <donald.h.fry@intel.com> Signed-off-by:
-
Don Fry authored
The op_mode should check for FW_ERROR before calling send_cmd. This removes the need to test for FW_ERROR in the trans layer. Signed-off-by:
-
Meenakshi Venkataraman authored
With error logging now completely handled in the op_mode, the transport layer does not need to know information about the loaded firmware. Remove this state information from the iwl_shared data structure. Signed-off-by:
Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by:
-
Meenakshi Venkataraman authored
iwl_get_single_channel_number is used only in iwl-scan.c, move it there and mark it static. Signed-off-by:
-
Meenakshi Venkataraman authored
iwl_full_rxon_required is used only in iwl-agn-rxon.c. Move it there and mark it static. Signed-off-by:
-
Meenakshi Venkataraman authored
iwl_check_rxon_cmd is used only in iwl-agn-rxon.c. Move it there and mark it static. Signed-off-by:
-
Meenakshi Venkataraman authored
iwl_set_rxon_hwcrypto is used only in iwl-agn-rxon.c. Move it there and mark it static. Signed-off-by:
-
Meenakshi Venkataraman authored
iwl_send_rxon_timing is used only in iwl-agn-rxon.c, move it there and mark it static. Signed-off-by:
-
Meenakshi Venkataraman authored
This is used only in one file, move it there and make it static. Signed-off-by:
-
Meenakshi Venkataraman authored
This variable holds the ucode currently running on the device; which is determined by op_mode, so move this parameter there. Also, the name of the variable is a bit misleading, so rename it to cur_ucode. Signed-off-by:
-
Meenakshi Venkataraman authored
Error log reporting does not belong to the transport layer, but to the op_mode loading the ucode, as it is the entity which knows about the ucode loaded, and what the error information means. Move device logging pointers from the transport layer to op_mode. With this change, transport layer only reports an error to the op_mode, which will figure out what to do with the error. This causes the driver to now dump out error logs when the command queue is stuck as well. Also, move the debugfs entry for event logs out of the transport layer and into op_mode. Signed-off-by:
-
Meenakshi Venkataraman authored
iwl_nic_error is used in iwl-agn.c only, move it there and make it static. Signed-off-by:
-
Meenakshi Venkataraman authored
In the process, make iwlagn_fw_error a non-static function, as it is used by more than one file. Signed-off-by:
-
Johannes Berg authored
No other component is accessing it any more, so it can move to the correct place in priv. Signed-off-by:
-
Johannes Berg authored
The queue mapping is not only dynamic, it is also dependent on the uCode, as we can already see today with the dual-mode and non-dual-mode being different. Move the queue mapping out of the transport layer and let the higher layer manage it. Part of the transport configuration is how to set up the queues. Signed-off-by:
-
Johannes Berg authored
As idle is just a deep powersave mode for the device, it will easily scan while idle since that turns off powersave. This reduces the number of commands sent to the device when scanning. Signed-off-by:
-
Johannes Berg authored
This is not (no longer?) used by any device so just remove it. Signed-off-by:
-
Johannes Berg authored
This is used only by 2000 class devices, but they all use it so remove the configuration parameter and hard-code the programming. Signed-off-by:
-
Johannes Berg authored
There's no device using this mechanism. Signed-off-by:
-
Johannes Berg authored
It talks about treating different uCode APIs as different pieces of hardware which really isn't how we handle things. Signed-off-by:
-
Johannes Berg authored
A whole bunch of messages, even some recent ones, didn't include a trailing newline so add it. Signed-off-by:
-
Johannes Berg authored
The calibration results all come in while we're waiting for the calibration complete notification. As a consequence, there's no need to install a global RX handler for them, we can use the newly extended notification wait framework for this and make the code easier to follow. It is now quite explicit that we are processing the calibration results while waiting for the complete notification, before this was implicit and developers had to know this to understand why we wait for the calibration complete notification and what happens while we wait. Signed-off-by:
-
Johannes Berg authored
Sometimes, for example when we ask the uCode for calibration, we wait for the "complete" response while we also need the results that are sent in other, interim, notifications. Currently we handle this by installing an RX handler globally, but that isn't needed as this is the only time we want to use these notifications. So in order to be able to simplify at least future code that does the same, extend the notification wait framework to allow you to wait for multiple commands and decide based on the command whether the wait finished. While at it, also fix a race that can then become relevant -- if the wait function has returned true once it shouldn't be called again, today this can happen due to races between the triggering and the wakeup. Signed-off-by:
-
