There's no need to take up the space for devices that don't
support WoWLAN, and most drivers can even make the support
data static const (except where it's modified at runtime.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For testing the D3 (WoWLAN) firmware, it is useful to be able
to run the firmware with instrumentation while the host isn't
sleeping and can poke at the firmware debug logging etc.
Implement this by a debugfs file. When the file is opened the
D3 firmware is loaded and all regular commands are blocked.
While the file is being read, poll the firmware's PME status
flag and report EOF once it changes to non-zero. When it is
closed, do (most of) the resume processing. This lets a user
just "cat" the file. Pressing Ctrl-C to kill the cat process
will resume the firwmare as though the platform resumed for
non-wireless reason and when the firmware wants to wake up
reading from the file automatically completes.
Unlike in real suspend, only disable interrupts and don't
reset the TX/RX hardware while in the test mode. This is a
workaround for some interrupt problems that happen only when
the PCIe link isn't fully reset (presumably by changing the
PCI config space registers which the core PCI code does.)
Note that while regular operations are blocked from sending
commands to the firmware, they could still be made and cause
strange mac80211 issues. Therefore, while using this testing
feature you need to be careful to not try to disconnect, roam
or similar, and will see warnings for such attempts.
Als note that this requires an upcoming firmware change to
tell the driver the location of the PME status flag in SRAM.
D3 test will fail if the firmware doesn't report the pointer.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The pointer that gets used is already const, so the
structs can obviously be const as well.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a number of parameters that aren't really hardware
specific but rather define how the DVM firmware is used.
Move these into the DVM configuration.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The next patches will move some more configuration
data that isn't needed by mvm into this struct, so
rename it now since it won't just be ops.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The MVM firmware doesn't communicate this way, it instead
assumes D3 configuration is complete after a specific host
command (which must be last) has been sent. Handling this
bit thus belongs into the firmware API code, i.e. DVM.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In 63b77bf489
iwlwifi: dvm: don't send zeroed LQ cmd
I tried to avoid to send zeroed LQ cmd, but I made a (very)
stupid mistake in the memcmp.
Since this patch has been ported to stable, the fix should
go to stable too.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58341
Cc: stable@vger.kernel.org
Reported-by: Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211 and the Intel drivers all define crypto
constants, move them to ieee80211.h instead.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the stations are being restored because of unassoc
RXON, the LQ cmd may not have been initialized because it
is initialized only after association.
Sending zeroed LQ_CMD makes the fw unhappy: it raises
SYSASSERT_2078.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
[move zero_lq and make static const]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We can check buf against NULL instead of having additional bool
variable.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If on iwl_dump_nic_event_log() error occurs before that function
initialize buf, we process uninitiated pointer in
iwl_dbgfs_log_event_read() and can hit "BUG at mm/slub.c:3409"
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=951241
Cc: stable@vger.kernel.org
Reported-by: ian.odette@eprize.com
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for the secondary channel offset IE in channel
switch announcements. This is necessary for proper handling
of CSA on HT access points.
For this to work it is also necessary to convert everything
here to use chandef structs instead of just channels. The
driver updates aren't really correct though. In particular,
the TI wl18xx driver update can't possibly be right since
it just ignores the new channel width for lack of firmware
API.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Until now we didn't handle properly the FLUSH ampdu action
coming from mac80211. This could result in SCD queue leak:
mac80211 would STOP_FLUSH an AMPDU Tx session and remove
the station. If we had still packets on the ring, we
wouldn't deallocate the SCD queue and wait for it to be
empty.
The indication of the queue being empty comes from the Tx
response flow which relies on the tid_data structure. The
problem is that this structure has been cleared when the
station has been removed.
In order to solve this issue, block in the STOP_FLUSH
ampdu_action until the SCD queue is flushed, and only then,
let mac80211 move forward to remove the station.
iwlagn_txfifo_flush had to be enhanced to allow this.
The bug fixed here caused the "txq_id mismatch: 12 0" print.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Using IWL_MVM_STATION_COUNT and IWL_INVALID_STATION together
isn't a good idea as they have different values. Always use
IWL_MVM_STATION_COUNT for an invalid station in MVM and move
the definition of the IWL_INVALID_STATION constant into the
DVM driver to avoid making such mistakes again. The one use
in the transport code can be hard-coded to -1 instead as the
station ID is passed as an integer there.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Many platforms have issues processing a wakeup signal
while they're still suspending, and will ignore it.
Since our device thinks it woke the platform, and the
platform ignored the signal, it will sleep without
WoWLAN being enabled as the device disables WoWLAN
when having woken the platform.
Resolve this by making the device wait for 10 seconds
after getting the suspend signal before waking up the
platform.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Alex Romosan reported that since the mac80211 changes in
"mac80211: start auth/assoc timeout on frame status" and
the subsequent fixes in "mac80211: fix auth/assoc timeout
handling" (commits 1672c0e319 and 89afe614c0) there's
sometimes an issue connecting to a 5 GHz network with the
iwlwifi DVM driver.
The reason appears to be that since these commits any bad
TX status makes mac80211 immediately try again, causing
all of the authentication attempts to be quickly rejected
by the firmware as it hasn't heard a beacon yet. Before,
it would wait for the timeout regardless of status.
To fix this, invoke the passive-no-RX workaround when not
associated yet as well. This will cause the first frame
to get lost, but then the driver will stop the queues and
the second attempt will only be transmitted after hearing
a beacon, thus delaying it appropriately to not make the
firmware reject it again.
Reported-by: Alex Romosan <romosan@sycorax.lbl.gov>
Tested-by: Alex Romosan <romosan@sycorax.lbl.gov>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers that don't use chanctxes cannot perform VHT association because
they still use a "backward compatibility" pair of {ieee80211_channel,
nl80211_channel_type} in ieee80211_conf and ieee80211_local.
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
[fix kernel-doc]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is a race between the restart flow and the workers.
The workers are cancelled after the fw is already killed
and might send HCMD when there is fw to handle them.
Simply check that there is a fw to which the HCMD can be
sent before actually sending it.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a number of situations in which mac80211 only
really needs to flush queues for one virtual interface,
and in fact during this frames might be transmitted on
other virtual interfaces. Calculate and pass a queue
bitmap to the driver so it knows which queues to flush.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This allows to test fw restart flow. The hook in transport
layer doesn't really make the fw assert. Moving this hook
to the op_mode allows to use the fw API to actually send a
host command that will make the fw assert.
Change the restart_fw module parameter to be a boolean on
the way.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All the data coming from the fw must have a length that is
multiple of 4.
This doesn't change anything to the way we handle the
notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
7000.c was released as GPL only by mistake: it should be
dual licensed - GPL / BSD.
The file that contains the license in the kernel is COPYING
and not LICENSE.GPL.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some devices can handle remain on channel requests differently
based on the request type/priority. Add support to
differentiate between different ROC types, i.e., indicate that
the ROC is required for sending managment frames.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move the sequence number arithmetic code from mac80211 to
ieee80211.h so others can use it. Also rename the functions
from _seq to _sn, they operate on the sequence number, not
the sequence_control field.
Also move macros to convert the sequence control to/from
the sequence number value from various drivers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Recently in commit 8a964f44e0
("iwlwifi: always copy first 16 bytes of commands") we fixed
the problem that the hardware writes back to the command and
that could overwrite parts of the data that was still needed
and would thus be corrupted.
Investigating this problem more closely we found that this
write-back isn't really ordered very well with respect to
other DMA traffic. Therefore, it sometimes happened that the
write-back occurred after unmapping the command again which
is clearly an issue and could corrupt the next allocation
that goes to that spot, or (better) cause IOMMU faults.
To fix this, allocate coherent memory for the first 16 bytes
of each command, containing the write-back part, and use it
for all queues. All the dynamic DMA mappings only need to be
TO_DEVICE then. This ensures that even when the write-back
happens "too late" it can't hit memory that has been freed
or a mapping that doesn't exist any more.
Since now the actual command is no longer modified, we can
also remove CMD_WANT_HCMD and get rid of the DMA sync that
was necessary to update the scratch pointer.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
I removed a bit too much info last time.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Theoretically, the card may not enter CTKILL:
In case the timer that iwl_prepare_ct_kill_task is setting,
will expire before tt->state revert to its previous state.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of modifying the HT SMPS capability field
for stations, track the SMPS mode explicitly in a
new field in the station struct and use it in the
drivers that care about it. This simplifies the
code using it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For VHT, many more bandwidth changes are possible. As a first
step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
in the HT capabilities and instead introduce a bandwidth field
indicating the currently usable bandwidth to transmit to the
station. Of course, make all drivers use it.
To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
the station as an argument, rather than the new capabilities,
so it can set up the new bandwidth field.
If the station is a VHT station and VHT bandwidth is in use,
also set the bandwidth accordingly.
Doing this allows us to get rid of the supports_40mhz flag as
the HT capabilities now reflect the true capability instead of
the current setting.
While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
ignore HT cap overrides when MCS TX isn't supported (not that it
really happens...)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the AP/GO beacon changes, apply such a change
immediately, otherwise the AP/GO beacon can be
stale for a long time.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Implement proper WoWLAN wakeup and query the wakeup
reasons, then report them to userspace.
Note that this is tricky: a firmware bug (that has
been fixed in later versions) means that the status
command response isn't properly closed in hardware
and thus won't arrive at the host. Sending another
command after it closes the status response but the
next command gets stuck, etc. We reset the device
after querying though, so this is not a big issue,
just makes for strange code.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are only a few drivers that use HW scan, and
all of those don't need a non-idle transition before
starting the scan -- some don't even care about idle
at all. Remove the flag and code associated with it.
The only driver that really actually needed this is
wl1251 and it can just do it itself in the hw_scan
callback -- implement that.
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixed-up drivers/net/wireless/iwlwifi/mvm/mac80211.c to change change
IEEE80211_HW_NEED_DTIM_PERIOD to IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC
as requested by Johannes Berg. -- JWL
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With new transports coming up, move to threaded
interrupt handling now. This has the advantage
that we can use the same locking scheme with all
different transports we may need to implement.
Note that the TX path obviously still runs in a
tasklet, so some spin_lock() calls need to change
to spin_lock_bh() calls to properly lock out the
TX path.
In my test on a Calpella platform this has no
impact on throughput or latency.
Also add lockdep annotations to avoid lockups due
to catch sending synchronous commands or using
locks that connect with them from the irq thread.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move the reg_lock that protects HW register access
into the transport implementation. Locking is no
longer exposed, but handled internally in grab and
release NIC access. This simplifies the users.
Signed-off-by: Lilach Edelstein <lilach.edelstein@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Express iwl_set_bit() and iwl_clear_bit() through iwl_set_bits_mask()
and add the latter to the transport's API in order to allow different
implementation for different transport types in the future.
Signed-off-by: Lilach Edelstein <lilach.edelstein@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As the rate scaling algorithm will attempt to enable
aggregation over and over again, the message will
flood the log if there is, for example, Bluetooth
streaming music. Make it a debug messages instead of
printing it all the time.
Reported-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, when the driver requires the DTIM period,
mac80211 will wait to hear a beacon before association.
This behavior is suboptimal since some drivers may be
able to deal with knowing the DTIM period after the
association, if they get it at all.
To address this, notify the drivers with bss_info_changed
with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM
becomes known. This might be when changing to associated,
or later when the entire association was done with only
probe response information.
Rename the hardware flag for the current behaviour to
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately
reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is
no longer accurate as all drivers get the DTIM period
now, just not before association.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since drivers can support several BSS / P2P Client
interfaces, the rssi callback needs to inform the driver
about the interface teh rssi event relates to.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit f590dcec94
which has been reported to cause issues.
See https://lkml.org/lkml/2013/1/20/4 for further details.
Cc: stable@vger.kernel.org [3.7]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Also when things go wrong (queues don't get emtpy), try to
get some data from the HW.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The rate scaling won't treat the information in a frame
with IEEE80211_TX_CTL_AMPDU set if IEEE80211_TX_STAT_AMPDU
is cleared. But all the frames coming from an AGG tx queue
have IEEE80211_TX_CTL_AMPDU set, and IEEE80211_TX_STAT_AMPDU
is set only if the frame was sent in an AMPDU.
This means that all the data in frames in AGG tx queues that
aren't sent as an AMPDU is thrown away.
This is even more harmful when in bad link conditions, the
frames are sent in an AMPDU and then finally sent as single
frame. So a lot of failures weren't reported and the rate
scaling got stuck in high rates leading to very poor
connectivity.
Fix that by clearing IEEE80211_TX_CTL_AMPDU when the frame
isn't part of an AMPDU.
This bug was introduced by
2eb81a40aa
iwlwifi: don't clear CTL_AMPDU on frame status
This fix basically reverts the aforementioned commit.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On resuming, the opmode may have to be able to talk
to the WoWLAN/D3 firmware in order to query it about
its status and wakeup reasons. To do that, the opmode
has to call the new d3_resume() transport API which
will set up the device for command communcation.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This allows to let sparse check that the NIC access is
always released.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix typo in the macro name and the wrong value.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_trans_grab_nic_access returns a boolean. So ret should
explicitely set to an error code and not rely on the value
returned by iwl_trans_grab_nic_access.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Different transports implement the access to the SRAM in
different ways. Virtualize it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since different transports have different ways to wake the
up the NIC, we need to virtualize it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use __packed instead of __attribute__((packed)).
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In some cases, the fw should run even if the NIC is in
RFKILL. Make the API more flexible to allow that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
No need to verify that the fw has been written correctly.
In case it hasn't, we won't get ALIVE notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If we take a pointer to the tid_data, then use it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When TX aggregation is stopped, there are a few
different cases:
- connection with the peer was dropped
- session stop was requested locally
- session stop was requested by the peer
- connection was dropped while a session is stopping
The behaviour in these cases should be different, if
the connection is dropped then the driver should drop
all frames, otherwise the frames may continue to be
transmitted, aggregated in the case of a locally
requested session stop or unaggregated in the case of
the peer requesting session stop.
Split these different cases so that the driver can
act accordingly; however, treat local and remote stop
the same way and ask the driver to not send frames as
aggregated packets any more.
In the case of connection drop, the stop callback the
driver is otherwise supposed to call is no longer
required.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We know that we have issues with the fw in the reclaim path.
This is why iwl_reclaim doesn't complain too loud when it
happens since it is recoverable. Somehow, the caller of
iwl_reclaim however WARNed when it happens. This doesn't
make any sense.
When I digged into the history of that code, I discovered
that this bug occurs only when we receive a BA notification.
So move the W/A in the BA notification handling code where
it was before.
This patch addresses:
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387
Cc: stable@vger.kernel.org
Reported-by: Florian Reitmeir <florian@reitmeir.org>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The WARN_ON_ONCE() check for scan_request will not correctly detect
a NULL pointer for scan_type == IWL_SCAN_NORMAL. Make it explicit
that the check only applies to normal scans.
Convert WARN_ON_ONCE to WARN_ON since priv->scan_request really _can't_
be NULL for normal scans. If it is then we should emit frequent warnings.
This smatch warning led to scrutiny of iwlagn_request_scan():
drivers/net/wireless/iwlwifi/dvm/scan.c:894 iwlagn_request_scan() error: we previously assumed 'priv->scan_request' could be null (see line 792)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
By using a few temporary variables, smatch can track
what's happening and stops complaining that we access
beyond the tid_data array.
This also makes the generated code a bit smaller, so
it's a win all around.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since we will have several forms of NVM (EEPROM, OTP, etc.)
and they will have different layouts, make the parsed data
more generic. This allows functional code to be independent
of a specific layout.
Also change some variables and function names from having
"eeprom" to "nvm" in their name.
Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It fixes a potential crash when receiving an LLCP HDLC frame acking a frame
that is not the last sent one. In that case we may dereference an already
freed pointer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQt0kOAAoJEIqAPN1PVmxKpxoQAJwbaylVz/miDjJLPekDhQ+z
YkDmtBWJD9oy5GS/EUZPRIIEj+Ftaao0lAJDP4couYiZPQbrRBY1llBOxcIzkCqR
fsAaD8jnPRGHwWtdqws8txFePh4Hn5WXHmJbcsOyVGt4gmy/xT06gme4p3VdIQIP
XIkbss5mz29OdQwOLHzH4zva7JtZm9XOEWYWAbbFsrgNxXLBt7GhfF92TT29K4Wt
UxFalwMYrpowY+BCBWzS1H31wVvNaDcsBRSO0hqvUZb7DgWM2b25B4Xnx3LiyLHR
9A17LWYso6mRhQPSqqhT5wWlKNT1G5VKZ8/X0i69ZLXi040NzpvMbvq41RhM9SwN
bmWZNUWGrGkQJY6VPAdXeraoSmSNwOD4KnLXNV8rWmmg+NSzf8ZPWNCcxNEdIMnK
oBe7vvk3j5z6QGNPeMB5C3hfpyRwyvRTqC9O5/dO7DOYD0lb0O6tuj1/MzhsOR2L
pzBUjkvfJBA0FXdeDD7gFwR062uJZL4hinRpFPj4qTtFWPYypirWdnRpCSZbvbeW
ZB3k7+8oNOGhn1TYPUmWsN1GNk2EJ4ZSpAf7BUI5Vb1KmcSpUQA6BN6yPlS/WQ4U
eowwW+sUYPu5LixMCO/LtuUllJ/RCTzdQJH6j/hZlEqmfYs00emKNa08tk15XjGF
zn2jXJjTykbYiVRirBR5
=tpAI
-----END PGP SIGNATURE-----
Merge tag 'nfc-fixes-3.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0
This is an NFC LLCP fix for 3.7 and contains only one patch.
It fixes a potential crash when receiving an LLCP HDLC frame acking a frame
that is not the last sent one. In that case we may dereference an already
freed pointer.
The vendor radiotap patch added a few fields to
struct ieee80211_rx_status that need to be zero,
initialize the struct instead of using whatever
was left on the stack.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As mwifiex (and mac80211 in the software case) are the
only drivers actually implementing remain-on-channel
with channel type, userspace can't be relying on it.
This is the case, as it's used only for P2P operations
right now.
Rather than adding a flag to tell userspace whether or
not it can actually rely on it, simplify all the code
by removing the ability to use different channel types.
Leave only the validation of the attribute, so that if
we extend it again later (with the needed capability
flag), it can't break userspace sending invalid data.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix a copy paste error in iwl_calc_basic_rates which leads
to a wrong calculation of CCK basic rates.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers (e.g. wl12xx) might need to know the vif
to roc on (mainly in order to configure the
rx filters correctly).
Add the vif to the op params, and update the current
users (iwlwifi) to use the new api.
Signed-off-by: Eliad Peller <eliad@wizery.com>
[fix hwsim]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When software crypto is enabled, it isn't safe
to enable MFP since the firmware interprets some
management packets, and with MFP it would do so
without proper validation.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Assaf Krauss <assaf.krauss@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the firmware is in SNIFFER mode, it leaves
the FCS at the end of frame. Not telling mac80211
means it won't add the right flag to the radiotap
header and that confuses wireshark.
Since mac80211 doesn't have a per-packet flag, set
the HW flag dynamically. This works as the monitor
vif can only be present in the driver by itself.
This fixes a regression introduced by my
commit 5789772641
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri May 11 10:53:18 2012 +0200
iwlwifi: support explicit monitor interface
Cc: stable@vger.kernel.org [3.5+]
Reported-by: MARK PHILLIPS <mark.phillips@virgin.net>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Allow drivers to indicate their mactime is at RX completion and adjust
for this in mac80211. Also rename the existing RX_FLAG_MACTIME_MPDU to
RX_FLAG_MACTIME_START to clarify its intent. Based on similar code by
Johannes Berg.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
[fix docs, atheros drivers]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no reason to print these all the time,
the messages aren't all that interesting. Leave
them as DEBUG_INFO though, just in case.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
To let mac80211 clean up any TX information when
a frame is dropped, use ieee80211_free_txskb().
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
People tend not to set the fields they want to leave as 0.
So make sure the struct is zeroed properly.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The ALIVE response of new fw inclues the base address of
the SCD in SRAM. Until we read it from a prph register,
which was set by the fw. Since the fw might well stop
updating the prph register, add a WARN when there is an
inconsitency between the ALIVE response and the register
to catch any change in the behavior.
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg