- 06 Mar, 2012 40 commits
-
-
Thomas Pedersen authored
Signed-off-by:
Thomas Pedersen <thomas@cozybit.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This doesn't belong into the op_mode, it has to be in the drv stop flow instead. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
-
Johannes Berg authored
Firmware request is a base driver flow, it isn't related to any specific mode. Move the code related to it into the base driver file iwl-drv.c. Signed-off-by:
-
Johannes Berg authored
This is used from there, so should be in it. Signed-off-by:
-
Johannes Berg authored
This shouldn't be in the op_mode, as it will later be switchable at runtime. Signed-off-by:
-
Johannes Berg authored
My patch "iwlwifi: simplify auth/assoc flow" caused a serious throughput degradation due to me forgetting that there are HT settings in the station table. To restore throughput, set these parameters correctly when the sta moves to assoc state. This patch should probably be merged with the auth/assoc redesign patch for upstream. In that case, this paragraph should be added to the commit log as the third paragraph (before talking about RXON): However, as we only get the station HT data when the station moves into assoc state, we also need to program this into the device (and copy it into our database) then. Signed-off-by:
-
Johannes Berg authored
These are DVM specific, and shouldn't be in iwl-shared.h. Signed-off-by:
-
Johannes Berg authored
Only used in two places in the same file, no need to be in iwl-shared.h. Signed-off-by:
-
Johannes Berg authored
Currently, queue mapping is handled in the transport. This may change, but until then the code for it can be close to where it's used rather than in iwl-shared.h. Signed-off-by:
-
Johannes Berg authored
This is how the transport passes things up into higher layers, so it belongs to the transport API. Signed-off-by:
-
Johannes Berg authored
iwl_queue_inc_wrap/iwl_queue_dec_wrap aren't shared functions, they are PCI-E specific, so move them into the appropriate header. Signed-off-by:
-
Johannes Berg authored
The annotation/documentation is wrong, we call it in a context that can't sleep. Signed-off-by:
-
Johannes Berg authored
Just make the code easier to read with less indentation. Signed-off-by:
-
Johannes Berg authored
struct iwl_rx_mem_buffer implementation details (DMA address, list pointers) that the upper layers don't need. Introduce iwl_rx_cmd_buffer that is passed upstream and only contains the needed data (the page). Additionally, access this data only via accessor functions, allowing us to change the implementation in the future. These accessors are rxb_addr() (as before) and rxb_steal_page() to take ownership of the data. Signed-off-by:
-
Johannes Berg authored
When CMD_WANT_SKB is set for a (synchronous) command, the response is passed back to the caller which is then responsible for freeing it. Make this more abstract with real API, passing directly the response packet in the new cmd.resp_pkt member and also introduce iwl_free_resp() to free the pages -- this way the upper layers don't have to directly touch the page implementation. NOTE: This breaks IDI -- the new code isn't reflected there yet! Signed-off-by:
-
Johannes Berg authored
We currently use the _irqsafe version, but that isn't recommended together with ieee80211_rx() as it can cause races. If the device reports a TX-status and RX in that order then with the current combination mac80211 might process them in the other order, which can cause issues with powersaving clients. Use ieee80211_tx_status() to avoid this race. Since we don't want to call it with locks held, process the frame queues later -- this is fine as they are on the stack. Signed-off-by:
-
Johannes Berg authored
With the new WoWLAN flow into the transport there no longer is a need for this to be shared, so move it into priv. Signed-off-by:
-
Johannes Berg authored
In the WoWLAN suspend flow, instead of accessing registers directly, ask the transport to do the required setup at the end of suspend. If the transport doesn't implement this, don't tell the stack we support WoWLAN. When the device suspends w/o WoWLAN, mac80211 will have stopped it already, which has already called iwl_apm_stop() via stop_hw(). Thus, it isn't necessary to call it again in pcie_suspend and we can simply do nothing there. This unifies the regular and WoWLAN suspend. Signed-off-by:
-
Johannes Berg authored
The code in the two branches of the #ifdef is almost the same so move the common code outside the #ifdef. Signed-off-by:
-
Johannes Berg authored
Writing to the global config structures is always wrong. To protect against such mistakes in the future, mark them const. Signed-off-by:
-
Johannes Berg authored
It's not really a good idea to write to the global static configuration. Use the valid TX/RX antenna information only from the HW params struct except in the case where the values from the config are used to override the values from the EEPROM. Signed-off-by:
-
Johannes Berg authored
There's no SKU override, we always just use it from EEPROM. As such, we can remove it from the config and use it in hw_param only. Since iwl_eeprom_check_sku() really needs to fill it in also rename that to iwl_eeprom_init_hw_params(). Signed-off-by:
-
Johannes Berg authored
There's no need for the per-device debug level that we expose in debugfs since the module parameter is writable in sysfs. At the same time, simplify code by changing iwl_get_debug_level(shrd) & IWL_DL_ISR) to iwl_have_debug_level(IWL_DL_ISR) Signed-off-by: -
Johannes Berg authored
With mac80211 now giving us station information (via the sta_state callback) before auth/assoc we can get rid of tx_sync by adding the station early for the case of managed interfaces. Keep AP mode actions the same for now. As we now get the BSSID early, we can also get rid of iwl_reprogram_ap_sta(). We can still optimise the number of RXONs we send to the device, but that can be done later. Signed-off-by:
-
Johannes Berg authored
There's no reason to set EXIT_PENDING when we start removing the module, as mac80211 will cleanly shut down the device in this case. Additionally, there's no point in rejecting commands to the device when we're cleaning up as that only leads to unwanted errors from mac80211 being printed, such as failed to remove key (...) from hardware (-16) Signed-off-by:
-
Johannes Berg authored
Some data doesn't need protection, some of the lock places are simply useless, and some data can be protected with the mutex instead. Thus the shared lock can be removed by making those changes. Signed-off-by:
-
Johannes Berg authored
The statistics are currently only half-heartedly locked against concurrent reading & modification so introduce a lock to really protect them. Signed-off-by:
-
Johannes Berg authored
Now that the transport has its own locking, there's no need to have the sta_lock in the shared data. Also, it can be a BH lock as it's not used from IRQ handlers. Signed-off-by:
-
Johannes Berg authored
Instead of (ab)using the sta_lock, make the transport layer lock its own TX queue data structures with a lock per queue. This also unifies with the cmd queue lock. Signed-off-by:
-
Johannes Berg authored
In the powersave related functions we only need to set a few parameters for the station command and can otherwise leave it blank -- there's no need to copy it from the database. This allows us to not use the sta lock here. Signed-off-by:
-
Johannes Berg authored
Simplify the code by returning directly in the error case and replacing the switch/if with a single if statement. Signed-off-by:
-
Johannes Berg authored
When we TX, we hold the sta_lock for a long time, a lot of which isn't needed. Reduce the time we hold the lock. Note that this doesn't really change anything as the code is already under the other spinlock, but it makes the code easier to read. Signed-off-by:
-
Johannes Berg authored
The station ID argument to the function iwlagn_tx_cmd_build_hwcrypto isn't used so remove it. Signed-off-by:
-
Johannes Berg authored
There's only one place using this function, so move it where it's needed. Signed-off-by:
-
Dan Carpenter authored
We should be doing a shift (1 << FLAG_RADIO_DOWN) here before testing the flag. As luck would have it, this test works almost correctly. The current code tests for FLAG_RADIO_OFF instead of FLAG_RADIO_DOWN. #define FLAG_RADIO_OFF 0 /* User disabling of MAC */ #define FLAG_RADIO_DOWN 1 /* ifup/ifdown disabling of MAC */ Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Johannes Berg authored
If we only monitor while associated, the following can happen: - we're associated, and the queue stuck check runs, setting the queue "touch" time to X - we disassociate, stopping the monitoring, which leaves the time set to X - almost 2s later, we associate, and enqueue a frame - before the frame is transmitted, we monitor for stuck queues, and find the time set to X, although it is now later than X + 2000ms, so we decide that the queue is stuck and erroneously restart the device It happens more with P2P because there we can go between associated/unassociated frequently. Cc: stable@vger.kernel.org Reported-by:
Ben Cahill <ben.m.cahill@intel.com> Signed-off-by:
-
Christian Lamparter authored
Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Christian Lamparter authored
Signed-off-by:
-
Jingjun Wu authored
Driver rtl8192ce when used with the RTL8188CE device would start at about 20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the symptoms is that the AP would need to retransmit each packet 4 of 5 times before the driver would acknowledge it. Recovery is possible only by unloading and reloading the driver. This problem was reported at https://bugzilla.redhat.com/show_bug.cgi?id=770207. The problem is due to a missing update of the gain setting. Signed-off-by:
Jingjun Wu <jingjun_wu@realsil.com.cn> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
Chun-Yeow Yeoh authored
This patch allows the possibility of having the mesh point and AP to be operated simultaneously in one single radio. Previously, mesh point fails to generate the mesh beacon if virtual AP is created for the same radio. Signed-off-by:
Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by:
-
