Advertise only user-requested bitrates in a HW scan.
Note that the hw_scan API doesn't currently have a
way of asking for a specific probe request bitrate,
so we might end up using a bitrate that we don't
advertise as supported. I'll fix that later.
Also add a hexdump printk to hwsim to verify this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move all that mac80211 has into the generic
ieee80211.h header file and use them. At the
same time move them from mask+shift to just
bits and rename them for consistent names.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fix was done according to si_clock_rate function in broadcom siutils.c
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Set up Kconfig and Makefile for new driver for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These patches allow compilation of rtlwifi, rtl8192c_common,
rtl8192ce, rtl8192cu and rtl8192se to compile after rtl8192de
was added.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines trx.c and trx.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines table.c and table.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines sw.c and sw.h for RTL8192SE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines rf.c and rf.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines reg.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines phy.c and phy.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines led.c and led.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines hw.c and hw.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines fw.c and fw.h for RTL8192DE.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Merge routines dm.c and dm.h for RTL8192DE.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Introduce routine def.h for rtl8192de.
Signed-off-by: Chaoming_Li <chaoming_li@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sometimes when reporting a MIC failure rx->key may be unset. This
code path is hit when receiving a packet meant for a multicast
address, and decryption is performed in HW.
Fortunately, the failing key_idx is not used for anything up to
(and including) usermode, so we allow ourselves to drop it on the
way up when a key cannot be retrieved.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently (3.0-rc2), modinfo iwlagn shows:
firmware: iwlwifi-5150-IWL5150_UCODE_API_MAX.ucode
firmware: iwlwifi-5000-IWL5000_UCODE_API_MAX.ucode
firmware: iwlwifi-6000g2b-IWL6000G2_UCODE_API_MAX.ucode
firmware: iwlwifi-6000g2a-IWL6000G2_UCODE_API_MAX.ucode
firmware: iwlwifi-6050-IWL6050_UCODE_API_MAX.ucode
firmware: iwlwifi-6000-IWL6000_UCODE_API_MAX.ucode
firmware: iwlwifi-100-IWL100_UCODE_API_MAX.ucode
firmware: iwlwifi-1000-IWL1000_UCODE_API_MAX.ucode
firmware: iwlwifi-105-IWL105_UCODE_API_MAX.ucode
firmware: iwlwifi-2030-IWL2030_UCODE_API_MAX.ucode
firmware: iwlwifi-2000-IWL2000_UCODE_API_MAX.ucode
which is obviously wrong, the user should not see the *_UCODE_API_MAX
macros but the actual ucode API versions here.
The problem are the
#define *_MODULE_FIRMWARE(api) *_FW_PRE #api ".ucode"
which do not expand api correctly (because this is a macro itself).
Fixed by using __stringify() from linux/stringify.h.
Further information about macro stringification can be found here:
http://gcc.gnu.org/onlinedocs/cpp/Stringification.html
Signed-off-by: Evgeni Golov <sargentd@die-welt.net>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Evidently, the device sometimes wants to write back
to command buffers, even if I see no reason why it
should. Allow it to do that.
Tested-by: Andy Lutomirski <luto@mit.edu>
Tested-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
When we stop the device while a command is in
flight that uses multiple TBs, we can leak the
DMA buffers for the second and higher TBs. Fix
this by using iwlagn_unmap_tfd() as we do when
we normally recover the entry.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
A recently added feature to the firmware enables the driver to retrieve
firmware logs via the host bus (SDIO or SPI).
There are two modes of operation:
1. On-demand: The FW collects its log in an internal ring buffer. This
buffer can later be read, for example, upon recovery.
2. Continuous: The FW pushes the FW logs as special packets in the RX
path.
Reading the internal ring buffer does not involve the FW. Thus, as long
as the HW is not in ELP, it should be possible to read the logs, even if
the FW crashes.
A sysfs binary file named "fwlog" was added to support this feature,
letting a monitor process read the FW messages. The log is transferred
from the FW only when available, so the reading process might block.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
During recovery work commands sent to the FW could fail and schedule
additional recovery work. Since the chip is going to be powered off,
avoid recursive recoveries.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The FW initialization might depend on the FW revision, so check for any
FW quirks right after booting it.
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When resuming (after wowlan), we want the rx packets (which is
usually the wake-up packet itself) to be passed to mac80211 only
after the resume notifier was completed, and mac80211 is up and
running (otherwise, the packets will be dropped).
By enqueueing the netstack_work to a freezable workqueue, we can
guarantee the rx processing to occur only after mac80211 was resumed.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
wl1271_flush_deferred_work(), which calls ieee80211_rx() and
ieee80211_tx_status(), is called from a process context.
hence, use ieee80211_tx_status_ni() instead of ieee80211_tx_status().
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When resuming while connected (without wowlan), the interface
is already IF_OPER_UP, so we won't get the notifier callback,
and hence never complete the association (from wl12xx perspective)
This situation, among other potential problems, prevents the
station from entering psm.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Some platforms don't support the wake_irq, so disable wowlan
in this case, and avoid the "Unbalanced IRQ wake disable"
warning on disable_irq_wake().
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Beacon filtering needs to be enabled so AP won't wake up by
by every received beacon.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
We set wl->wow_enabled on every suspend(), so we need to clear it
on every resume().
(we can't rely on setting wl->wow_enabled=false in suspend(),
as it being called only when wowlan triggers are configured)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Since mac80211 calls suspend/resume only when wowlan triggers
exist, there is no need to check for triggers existance in the
callbacks as well.
Add a WARN_ON() to verify it.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The Low Power DRPw (LPD) mode contains several optimizations
that designed to reduce power consumption. The purpose
is to save current consumption in RX and Listen mode.
LPD setting apply only for wl127x AP mode (not wl128x)
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
If our SDIO function has its runtime PM disabled, don't try to
manipulate its runtime PM status at all. This way we can still
power on cards plugged to mmc hosts that are not MMC_CAP_POWER_OFF_CARD.
Reported-and-tested-by: Tim Yamin <tim@kangatronix.co.uk>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
The firmware, in practice, treats the channels in three separate
blocks, one for each band (bg, a and j). Instead of using a single
array and doing some magic with indices, split the array in 3 to make
it more readable.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Due to rebase error, the patch for commit cb5ae0 ("wl12xx: configure
rates when working in ibss mode") was wrong - a blob was added
into the wrong function. fix it.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
crc7 is used only in wl12xx_spi.
Remove redundant crc7.h includes, and update Kconfig to select CRC7
only if WL12XX_SPI is being selected.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Beacon early termination doesn't help much in the 5GHz band and masks
channel switch IE Beacons. Thus, change the code to use BET only in
2.4GHz.
[Reworded the commit log slightly -- Luca.]
Signed-off-by: Shahar Levi <shahar_levi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Allow control over rx_streaming interval and operation mode
(always/only on coex) via debugfs.
e.g.
echo 100 > /debug/ieee80211/phy0/wl12xx/rx_streaming/interval
echo 1 > /debug/ieee80211/phy0/wl12xx/rx_streaming/always
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
When rx_streaming.interval is non-zero, use automatic rx streaming.
Enable rx streaming on the each rx/tx packet, and disable it
rx_streaming.duration msecs later.
When rx_streaming.always=0 (default), rx streaming is enabled only
when there is a coex operation.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
wl12xx supports the "rx streaming" feature:
When in ps mode, and @timeout msecs have been passed since
the last rx/tx, it issues trigger packets (QoS-null/PS-Poll packets,
according to the ac type) in const intervals (in order to reduce
the rx time).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Those have little value. Remove those to
make the driver less noisy.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Nops aren't needed. When we actually need
those calls, then we add them with meat
and barbecue sauce.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
->init and ->reset are optional - at least
sdio.c doesn't implement them - so allow those
pointers to be NULL.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Those have little value. Remove those to make
the driver less noisy.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
That's only needed during init anyway, let's free
some space after we're done probing.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
net/bluetooth/smp.c: In function 'smp_e':
net/bluetooth/smp.c:49:21: error: storage size of 'sg' isn't known
net/bluetooth/smp.c:67:2: error: implicit declaration of function 'sg_init_one'
net/bluetooth/smp.c:49:21: warning: unused variable 'sg'
Caused by commit d22ef0bc83 ("Bluetooth: Add LE SMP Cryptoolbox
functions"). Missing include file, presumably. This batch has been in
the bluetooth tree since June 14, so it may have been exposed by the
removal of linux/mm.h from netdevice.h ...
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
P2P interfaces must not use CCK rates, only OFDM
rates are allowed. To set this up, we need to set
up the broadcast station to start with 6M instead
of starting with 1M.
Since the interface type can change, also reset
the broadcast station when RXON changes.
This will affect beacons as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Use the rate that mac80211 requested to fill the
uCode TX command for the beacon. Unfortunately,
the uCode is (currently?) ignoring it, but now
at least fill it properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
We've infrequently seen timeouts, make the wait time
match the windows driver; hopefully our driver is
just too impatient.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
