- 02 Nov, 2009 6 commits
-
-
Ben Cahill authored
Invoke workaround to avoid instability in L0->L0S->L1 transition on PCIe bus. Workaround disables L0S state so device moves directly from L0->L1. Workaround needed on all devices since and including 4965; add to 6000/1000. Describe bug and workaround better in comments. Signed-off-by: Ben Cahill <ben.m.cahill@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Cahill authored
To save power, don't run apm_ops.init() until needed at "up" time. EEPROM (5000 and earlier devices) may be read without running apm_ops.init(), but OTP reads (6000 and newer devices) require a powered-up chip. Therefore, remove apm_ops.init() from the general path in XXXX_pci_probe(), and call it only if device uses OTP. Once done with OTP read, call apm_ops.stop() to reset chip and save power until "up" time comes around. NOTE: This patch depends on removal of priv->lock from iwl_apm_stop(); lock does not get initialized until later in flow. See patch "remove unneeded locks from apm_stop()". Signed-off-by: Ben Cahill <ben.m.cahill@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Cahill authored
Since priv->reg_lock was added to keep multi-access register manipulation atomic, priv->lock protection is no longer needed. Remove this from iwl_apm_stop_master() and iwl_apm_stop(). Add warning of timeout when polling for busmaster disablement confirmation, and some comments. NOTE: This is needed to enable use of apm_ops.stop() within iwl_eeprom_init(); priv->lock does not get initialized until after this flow. See patch "remove power-wasting calls to apm_ops.init()" Signed-off-by: Ben Cahill <ben.m.cahill@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Reinette Chatre authored
By setting the firmware version in wiphy it is possible to obtain this information via ethtool. Some examples, # ethtool -i wlan1 driver: iwlagn version: 2.6.32-rc5-wl-56840-g26d8540 firmware-version: 228.57.2.23 bus-info: 0000:03:00.0 # ethtool -i wlan0 driver: iwl3945 version: 2.6.32-rc5-wl-56840-g26d8540 firmware-version: 15.28.2.8 bus-info: 0000:02:00.0 Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The multi-line code in this macro wasn't wrapped in do {} while (0) so we cannot use it in an if() branch safely in the future -- fix that. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Andrey Yurovsky authored
This patch removes the internal command and data buffers that the GSPI driver maintained and instead relies on the Libertas core to synchronize access to the command and data ports as with the other interface drivers. This cleanup reduces the GSPI driver's memory footprint and should improve performance by removing the need to copy to these internal buffers. This also simplifies the bottom half of the interrupt handler. This is an incremental cleanup: after removing the redundant buffers, we can further improve the driver to use a threaded IRQ handler instead of maintaining its own thread. However I would like a few folks to test the buffer removal first and make sure that I'm not introducing regressions. Tested on Blackfin BF527 with DMA disabled due to an issue with the SPI host controller driver in the current bleeding-edge Blackfin kernel. I would appreciate it if someone with working DMA could test this patch and provide feedback. Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Tested-by: George Shore <george.shore@imgtec.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 30 Oct, 2009 34 commits
-
-
Larry Finger authored
This patch is adapted from the submission by Michael Buesch <mb@bu3sch.de> for a bounce-buffer copying problem with b43. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
It's not right to do something here when returning an error, and hostapd should never have relied on it as it only fixes up a small part of the problem anyway. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This variable is set once, and tested once. However, the code path that can set it is mutually exclusive with the code path that tests it, so the test is always true. Thus we also don't need to set it either and can just remove the variable. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We drop nullfunc frames, but not qos-nullfunc frames, even though those could be used for PS state control as well. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luciano Coelho authored
The check after the loop which checks whether the initialization timed-out was wrong. If the initialization would succeed exactly in the 20000th time (the value set for INIT_LOOP), the driver would bail out and claim that initialization failed. Reported-by: Juha Leppanen <juha_motorsportcom@luukku.com> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Reviewed-by: Janne Ylalehto <janne.ylalehto@nokia.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When mac80211 is asked to buffer multicast frames in AP mode, it will not set the flag indicating that the frames should be sent after the DTIM beacon for those frames buffered in software. Fix this little inconsistency by always setting that flag in the buffering code path. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This value is unused by mac80211, because it was only be used by wireless extensions, and turned out to not be useful there because the quality value needs to be comparable between scan results and the current value which is impossible when the qual value is calculated taking into account noise, for example. Since it is unused anyway, this patch deprecates it in the hope that drivers will remove their sometimes quite expensive calculations of the value. I'm open to actual uses of the value, but the best way of using it seems to be what the Intel drivers do which should probably be generalised if we have noise values from the hardware. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Compared to ieee80211_beacon_get(), the new function ieee80211_beacon_get_tim() returns information on the location and length of the TIM IE, which some drivers need in order to generate the TIM on the device. The old function, ieee80211_beacon_get(), becomes a small static inline wrapper around the new one to not break all drivers. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Randy Dunlap authored
airo_cs uses spy interfaces so it needs to select WEXT_SPY. ERROR: "iw_handler_set_thrspy" [drivers/net/wireless/airo.ko] undefined! ERROR: "wireless_spy_update" [drivers/net/wireless/airo.ko] undefined! ERROR: "iw_handler_get_spy" [drivers/net/wireless/airo.ko] undefined! ERROR: "iw_handler_get_thrspy" [drivers/net/wireless/airo.ko] undefined! ERROR: "iw_handler_set_spy" [drivers/net/wireless/airo.ko] undefined! Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
This fixed a BUG_ON in __skb_trim() when paged rx is used in iwlwifi driver. Yes, the whole mac80211 stack doesn't support paged SKB yet. But let's start the work slowly from small code snippets. Reported-and-tested-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
To do this we reorder callers in order in which they are called. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Force bias is a fix for usage of AR5416 radios on the 2.4 GHz band for orientation sensitivity. This was only partially implemented with the ath9k_hw_decrease_chain_power() but first -- this was being called for all chipsets which is not correct and second -- it was missing the actual orientation code. We now ensure to only enable force bias only for AR5416 and BUG_ON() on other chipsets. Although ath9k_hw_decrease_chain_power() was enabled for newer chipsets I suspect that it never ran unless the EEPROM had ATH9K_ANT_FIXED_A or ATH9K_ANT_FIXED_B for antenna diversity. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This only differs between single-chip solutions and non single-chip solutions. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This reorders phy.c routines in the order in the order in which they are used and also moves the spur mitigation helpers for each type of chip into phy.c as they are RF related. This patch has no functional changes. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This avoids a branch on every channel change. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This allows us to later define a callback for both. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This clarifies this is only required for external radios. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This is calling an allocation and checking for it, simplify this process in a macro. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
ath9k_hw_rfattach() was just calling a helper and this helper was doing nothing for single-chip devices, and for non single-chip devices it is just allocating memory for banks to program the RF registers at a later time. Simplify this by having the hw initialization call the rf bank allocation directly for external radios. Also, propagate an -ENOMEM properly now upon failure. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We a huge branch for old hardware and nothing for newer hardware. Instead of doing this just bail out early for newer hardware. This patch has no functional changes. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Document what we can about the RF analog front ends (radios) of Atheros 802.11n devices. What should be clearer now is the what we do for old pre AR5416 and AR5418 MAC based devices in comparison to the modern sigle-chip 802.11n solutions. All devices after AR9280 are single chip and require less programming -- the RF registers no longer need to be initialized as they all have the RF analog front end embedded together with the MAC/BB; this includes the AR9271. Older devices such as the ones with the AR5416 MACs (PCI) or AR5418 MACs (PCI-E) have an external 2.4 GHz AR2133 radio or a dual band 2.4 GHz / 5 GHz AR5133 radio. These external radios require additional programming of the RF registers. Clarify which parts are for what devices and which code is shared. This patch has no functional changes. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We adjust the core clock for ar9271 to 117 MHz; this also requires us to adjust the baud divider based on the targetted baud rate. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This update the register initialization/reset values (aka initvals) for ar9271 based on the last recommended values on 2009-06-04 by our systems engineering team. The changes account for: * Supporting ar9271 1.0 and ar9271 1.1 together, the difference is bb_spectral_scan_ena, for 1.0 we'll set this to 0x1. * Ensuring we get the correct noise floor values -115 ~ -118 when we enable bb_enable_ant_div_lnadiv=0 and mc_tx_def_ant_sel=1. Previous to this we would get noise floor values in the range -50 ~ -80. To fix settings for the registers: - bb_ch1_xatten1_db - bb_ch1_xatten2_db - bb_ch1_xatten1_margin - bb_ch1_xatten2_margin - bb_ch1_gain_force - bb_ch1_xatten2_hyst_margin - bb_ch1_xatten1_hyst_margin - bb_ch1_max_oc_gain * 0x8120[2] mc_mic_new_location_enable is changed to 0x1. The MAC team suggest to set this value. * 0x9910[0] bb_spectral_scan_ena is changed to 0x0. For ar9271 1.1 we don't need to enable this bit. Cc: Stephen Chen <Stephen.Chen@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Greg Kroah-Hartman authored
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
With the WLAN_PRE80211 drivers moved to drivers/staging, this distinction becomes unnecessary. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Move the netwave driver to drivers/staging. This is another pre-802.11 driver that has seen virtually no non-API-fixup activity in years, and for which no active hardware is likely to still exist. This driver represents unnecessary ongoing maintenance for no clear benefit. This patch brought to you by the "hacking" session at the 2009 Kernel Summit in Tokyo, Japan... Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Move the wavelan driver to drivers/staging. This is another pre-802.11 driver that has seen virtually no non-API-fixup activity in years, and for which no active hardware is likely to still exist. This driver represents unnecessary ongoing maintenance for no clear benefit. This patch brought to you by the "hacking" session at the 2009 Kernel Summit in Tokyo, Japan... Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Move the arlan driver to drivers/staging. This is another pre-802.11 driver that has seen virtually no non-API-fixup activity in years, and for which no active hardware is likely to still exist. This driver represents unnecessary ongoing maintenance for no clear benefit. This patch brought to you by the "hacking" session at the 2009 Kernel Summit in Tokyo, Japan... Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Move the strip ("Starmode Radio IP") driver to drivers/staging. For several years this driver has only seen API "bombing-run" changes, and few people ever had the hardware. This driver represents unnecessary ongoing maintenance for no clear benefit. This patch brought to you by the "hacking" session at the 2009 Kernel Summit in Tokyo, Japan... Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-