- 08 Aug, 2011 38 commits
-
-
Johannes Berg authored
The availability of contexts depends on the firmware capabilities. Currently only the presence of the second context depends on it, but soon P2P support will also be different. Move the context initialisation code to the firmware-dependent setup before registering with mac80211 to make it easier to handle. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We're working on improvements for the firmware for some devices, and need to bump the API for those since they won't be backward compatible completely (the earlier patch reserving queue 10 for P2P). Bump the API version to 6 for those devices but don't warn users of version 5 yet. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We sometimes need to support new firmware API for a while before we can publish them since testing them fully takes a long time. We could keep all the new code private, but that causes plenty of problems and sometimes we can give a pre-release version of firmware to people who need to test. However, when we just bump the API version, the driver will warn everybody that their firmware is outdated, when in fact it isn't. (Currently our case for this doesn't really change the API but bumping the API version is necessary because the firmware isn't fully backward compatible) In order to handle this in the future, add a new "api_ok" version; only below this will the driver warn that the uCode is too old. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
For _bgn device, remove ht40 support for 5.2GHz, it is probably ok since the "band" is not support but just feel strange. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
1000 series are 1x2 devices, the old default using static smps which only use single antenna for rx, set the default to dynamic smps. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
New uCode images will use queue 10 for TX during scan (for P2P offchannel operation scan). We'll bump the API version of those, but before we need to reserve queue 10 and stop using it for aggregation. To simplify the code, always reserve it, we could continue using it on older uCode images but that'd be rather complicated. Also, we'll set it up to map to the right FIFO as needed later, but as we don't use the queue now that doesn't hurt. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Pavel Roskin authored
When checking for the band, use channel->band. Change ath5k_hw_nic_wakeup() and ath5k_channel_ok() to take ieee80211_channel. Change ath5k_hw_radio_revision() to take ieee80211_band. Signed-off-by: Pavel Roskin <proski@gnu.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Pavel Roskin authored
XR is a proprietary feature of the chipset. It's not supported and should not be supported. Signed-off-by: Pavel Roskin <proski@gnu.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Pavel Roskin authored
struct ath5k_avg_val is unused. In struct ath5k_hw, lladdr, ah_radar and ah_mac_revision are write-only, rxbufsize is unused, ah_phy is write-only and referenced by unused macros. In struct ath5k_vif, lladdr is write-only. Remove AR5K_TUNE_RADAR_ALERT, which has no effect. Signed-off-by: Pavel Roskin <proski@gnu.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Pavel Roskin authored
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This patch add support for the bcma bus. Broadcom uses only Mips 74K CPUs on the new SoC and on the old ons using ssb bus there are no Mips 74K CPUs. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Prepare bcm47xx to support different System buses. Before adding support for bcma it should be possible to build bcm47xx without the need of ssb. With this patch bcm47xx does not directly contain a ssb_bus, but a union contain all the supported system buses. As a SoC just uses one system bus a union is a good choice. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Add method to return the clock of the CPU. This is needed by the arch code to calculate the mips_hpt_frequency. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This adds support for serial console to bcma, when operating on an SoC. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This adds a mips driver to bcma. This is only found on embedded devices. For now the driver just initializes the irqs used on this system. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This patch adds support for using bcma on a Broadcom SoC as the system bus. An SoC like the bcm4716 could register this bus and use it to searches for the bcma cores and register the devices on this bus. BCMA_HOSTTYPE_NONE was intended for SoCs at first but BCMA_HOSTTYPE_SOC is a better name. Acked-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
The chip common and mips core have to be setup early in the boot process to get the cpu clock. bcma_bus_early_register() gets pointers to some space to store the core data and searches for the chip common and mips core and initializes chip common. After that was done and the kernel is out of early boot we just have to run bcma_bus_register() and it will search for the other cores, initialize and register them. The cores are getting the same numbers as before. Acked-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
This makes it possible to use this code in some other method. Acked-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hauke Mehrtens authored
Move the parsing of the EEPROM data in scan function for one core into an own function. Now we are able to use it in some other scan function as well. Acked-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Sergei Shtylyov authored
The driver reads PCI subsystem ID from the PCI configuration register while it's already stored by the PCI subsystem in the 'subsystem_device' field of 'struct pci_dev'... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
mwifiex_get_bss_info() routine updates variable 'info->scan_table_idx' but it is never used. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Daniel Drake authored
Currently, "udevadm info -a -p /sys/class/net/wlan0" doesn't mention the usb8xxx or libertas driver anywhere. This makes writing udev rules a bit uncomfortable. Using the USB interface as the parent device corrects the hierarchy. Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Daniel Drake authored
The mesh device is now exposed as an interface of the wiphy. This exposes the mesh device to the cfg80211 interface, allowing mesh channel selection to be reimplemented, and available to NetworkManager as it was before. Some header tweaking was needed in order to implement lbs_mesh_activated(). Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
A lot of code is dedicated to giving drivers the ability to use cfg80211's wext handlers without completely converting. However, only orinoco is currently using this, and it is only partially using it. We reduce the size of both the source and binary by removing those that nobody needs. If a driver shows up that needs it during conversion, we can add back those that are needed. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
replace IW_MAX_AP & IW_CUSTOM_MAX with local definitions and remove usage of struct iw_statistics. Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h is for wireless extensions only, so mac80211 shouldn't include it since it uses cfg80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
In trying to remove the wext includes from mac80211 and cfg80211 I found that mwifiex currently uses them. This is wrong, it shouldn't, but to not break it completely include wext there. Please remove this and fix all the resulting bugs. Cc: Bing Zhao <bzhao@marvell.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This driver uses IW_ESSID_MAX_SIZE when it should be using IEEE80211_MAX_SSID_LEN instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This driver uses IW_ESSID_MAX_SIZE when it should be using IEEE80211_MAX_SSID_LEN instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h and net/iw_handler.h headers are for wireless extensions only, so mac80211 drivers shouldn't be including them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h and net/iw_handler.h headers are for wireless extensions only, so mac80211 drivers shouldn't be including them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h and net/iw_handler.h headers are for wireless extensions only, so mac80211 drivers shouldn't be including them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h and net/iw_handler.h headers are for wireless extensions only, so mac80211 drivers shouldn't be including them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Pavel Roskin <proski@gnu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h and net/iw_handler.h headers are for wireless extensions only, so mac80211 drivers shouldn't be including them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
linux/wireless.h and net/iw_handler.h headers are for wireless extensions only, so mac80211 drivers shouldn't be including them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
A lot of drivers erroneously use wext constants and don't notice since cfg80211.h includes them. Make this more split up so drivers needing wext compatibility from cfg80211 need to explicitly include that from cfg80211-wext.h. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 03 Aug, 2011 1 commit
-
- 02 Aug, 2011 1 commit
-
-
Wey-Yi Guy authored
5000 series has issue supporting power save idle mode: commit 9dc21533 iwlwifi: always support idle mode for agn devices For agn devices, always support idle mode which help power consumption in idle unassociated state. the above changes cause 5000 become not stable when power management is "on" http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2312 Cc: stable@kernel.org #2.6.39, #3.0.0 Reported-by: Devin J Pohly <djpohly+iwl@gmail.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-