Age | Commit message (Collapse) | Author | Files | Lines |
|
Some static checkers (e.g. smatch) complain if a non-constant
format string is used, even if that's a static const variable.
Since there's no impact on code generation, just change those
format strings to be macros.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Fix the kernel-doc, and remove some fields even the firmware doesn't
use in ToF, RX, scan, station and generic FW APIS.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Fix various "Excess struct/union/enum/typedef member '...' description
in '...'" warnings from kernel-doc, mostly caused by typos.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Add a debugfs entry to get a verbose description of the power settings
used in each band with the currently selected SAR geographic profile.
Signed-off-by: Haim Dreyfuss <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
We are going to add debugfs entry to retrieve the current geographic
profile being used in the FW. Currently the driver reads those tables
from the BIOS and passes them to the FW.
To prepare for this retrieving we want to store those
tables in the driver.
Signed-off-by: Haim Dreyfuss <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
More iwlwifi patches for 4.13
* Some changes in suspend/resume handling to support new FWs;
* A bunch of RF-kill related fixes;
* Continued work towards the A000 family;
* Support for a new version of the TX flush FW API;
* Some fixes in monitor interfaces;
* A few fixes in the recovery flows;
* Johannes' documentation fixes and FW API struct cleanups continue;
* Remove some noise from the kernel logs;
* Some other small improvements, fixes and cleanups;
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.13
New features and bug fixes to quite a few different drivers, but
nothing really special standing out.
What makes me happy that we have now more vendors actively
contributing to upstream drivers. In this pull request we have patches
from Broadcom, Intel, Qualcomm, Realtek and Redpine Signals, and I
still have patches from Marvell and Quantenna pending in patchwork. Now
that's something comparing to how things looked 11 years ago in Jeff
Garzik's "State of the Union: Wireless" email:
https://lkml.org/lkml/2006/1/5/671
Major changes:
wil6210
* add low level RF sector interface via nl80211 vendor commands
* add module parameter ftm_mode to load separate firmware for factory
testing
* support devices with different PCIe bar size
* add support for PCIe D3hot in system suspend
* remove ioctl interface which should not be in a wireless driver
ath10k
* go back to using dma_alloc_coherent() for firmware scratch memory
* add per chain RSSI reporting
brcmfmac
* add support multi-scheduled scan
* add scheduled scan support for specified BSSIDs
* add support for brcm43430 revision 0
wlcore
* add wil1285 compatible
rsi
* add RS9113 USB support
iwlwifi
* FW API documentation improvements (for tools and htmldoc)
* continuing work for the new A000 family
* bump the maximum supported FW API to 31
* improve the differentiation between 8000, 9000 and A000 families
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
When trying to TX through a monitor interface, the
conditions in iwl_mvm_tx_skb_non_sta() don't match
and the frame tries to go out from an usued TXQ.
Add a check for monitor iface, and use the AUX queue
in such a case.
In non-DQA mode the frame is sent through the
static-allocated queues anyway, so the problem is
in DQA mode only.
Signed-off-by: Liad Kaufman <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
In some platforms, having the device enabled with certain radio
frontends causes the platform to not be able to resume properly
from suspend, regardless of the wakeup cause. This was traced to
a hardware issue with the integrated 9000-series A-step variant.
Set the right hardware bit to disable the problematic state.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Signed-off-by: Chaya Rachel Ivgi <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
When the firmware crashes, the transmit queues can't make
any progress. This is why we stop the counter that monitor
the transmit queues' activity.
The call that notifies the error to the op_mode may take
a bit of time, so stop the timer of the transmit queues
earlier.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
The driver prints "L1 Enabled - LTR Enabled" all the time as dev_info,
which is just useless noise in most cases. Convert this to
IWL_DEBUG_POWER() so we don't pollute the log unnecessarily but still
can get this info on demand.
Signed-off-by: Luca Coelho <[email protected]>
|
|
It's sometimes hard to find out which HW address the iwlwifi device is
using, for instance when reading crouded sniffer logs. To make it
easier, print out an info level message with the HW address as soon as
we know it.
Signed-off-by: Luca Coelho <[email protected]>
|
|
Document the assoc_beacon_arrive_time element in the iwl_mac_data_sta
struct.
Signed-off-by: Luca Coelho <[email protected]>
|
|
This new API allows flushing queues based on station ID and TID in A000
devices. One reason for using this is that tfd_queue_mask is only good
for 32 queues, which is not enough for A000 devices.
Signed-off-by: Sara Sharon <[email protected]>
Signed-off-by: Mordechai Goodstein <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
When we get an ASSERT, the fw_dump_desc pointer points to
iwl_mvm_dump_desc_assert which can't be freed since it is
a global. We still need to NULL'ify the pointer when we
call iwl_mvm_free_fw_dump_desc otherwise we will hit
int iwl_mvm_fw_dbg_collect_desc(struct iwl_mvm *mvm,
const struct iwl_mvm_dump_desc *desc,
const struct iwl_fw_dbg_trigger_tlv *trigger)
{
<snip>
if (WARN_ON(mvm->fw_dump_desc))
iwl_mvm_free_fw_dump_desc(mvm);
Fixes: b6eaa45aa18b ("iwlwifi: mvm: add the cause of the firmware dump in the dump")
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
When updating the mac context after association,
assoc_beacon_arrive_time is not being set, which causes the FW to
set a wrong TSF to the MAC.
Fix this by setting the assoc_beacon_arrive_time when updating the
mac context after association.
Signed-off-by: Avraham Stern <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Nothing ever checks the return value of iwl_pcie_apm_stop_master(),
so there's no point in it having one - make it return void.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
In case we need to move the scheduler write pointer by
steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck.
This leads to hardware error interrupts with status:
0x5A5A5A5A or alike.
In order to work around this, detect in the transport
layer that we are going to hit this case and tell iwlmvm
to increment the sequence number of the packets. This
allows to keep the requirement that the WiFi sequence
number is in sync with the index in the scheduler Tx queue
and it also allows to avoid the problematic sequence.
This means that from time to time, we will start a queue
from ssn + 1, but that shouldn't be a problem since we
don't switch to new queues for AMPDU now that we have
DQA which allows to keep the same queue while toggling
the AMPDU state.
This bug has been fixed on 9000 devices and up.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
A TID may not have traffic but still have a BA agreement
active (or being setup / torn down) since a BA agreement
can be triggered by a debugfs hook.
Just avoid to consider such a TID as inactive to make the
logic safer.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
If the hardware is stuck, we can't read any of the memory we need to
dump it, so we end up printing only 0xa5a5a5a5, which is useless.
To solve this, poke the hardware by triggering a reset and re-enabling
the clocks if we detect a HW error.
Signed-off-by: Luca Coelho <[email protected]>
|
|
When we started using threaded irqs, all the opmode calls were changed
to be called with local_bh disabled. The reason for this was it was
that mac80211 needs that. When we are handling FW errors, mac80211 is
not involved, so we don't need it.
Signed-off-by: Luca Coelho <[email protected]>
|
|
In BSS mode in the disconnection flow, mac80211 removes
the AP station before the vif is set to unassociated.
Our firmware wants it the other way around: first set
the vif as unassociated, and then remove the AP station.
In order to bridge between those two different behaviors,
iwlmvm doesn't remove the station from the firmware when
mac80211 removes it, but only after the vif is set to
unassociated. The implementation is in
iwl_mvm_bss_info_changed_station:
if (assoc state was modified && mvmvif->ap_sta_id is VALID
&& assoc state is now UNASSC)
remove_the_station_from_the_firmware()
During the recovery flow, mac80211 re-adds the AP station
and then reconfigures the vif. Since the vif is not
associated, and then, we enter the if above (which was
intended to be taken in the disconnection flow only) and
remove the station we just added. This defeats the
recovery flow.
Fix this by not removing the AP station in this flow if
we are in recovery flow.
Cc: [email protected]
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
We allocate nvm_data in iwl_mvm_nvm_get_from_fw(). If something goes
wrong after the allocation (i.e. if no valid MAC address is valid), we
should free nvm_data before returning an error.
Signed-off-by: Luca Coelho <[email protected]>
|
|
This function just calls kfree(), so it only obscures the code without
bringing any benefits. Remove it.
Signed-off-by: Luca Coelho <[email protected]>
|
|
Properly document the transmit buffer bits using an enum and
kernel-doc documentation.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Add kernel-doc documentation for enum iwl_debug_cmds, linking the
structures used by the commands.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
This improves documentation, since kernel-doc can't deal with the
union well.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
To stop and start the FW monitor in the 7000 HW
family we need to use a different bit, otherwise
after stopping it for the first time - it won't
get restarted. Use the correct bitmask.
Note: This fix is only for DRAM collection mode.
For other modes, an additional fix will be
needed.
Signed-off-by: Liad Kaufman <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Fix the enum link by adding the missing & and provide the link
to the TX response documentation.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
When the command name is printed on command completion, the wrong
group is used, leading to the wrong name being printed. Fix this
by using the group ID without inappropriately mangling it through
iwl_cmd_groupid() - it's already a u8. Also, while at it, use it
from the same place as the command ID, everything else is just
confusing.
Fixes: ab02165ccec4 ("iwlwifi: add wide firmware command infrastructure for TX")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
When sending non-linear SKBs that should be included in the regular
TX tracing completely (and not be pushed into the tx_data tracing),
the (tracing) code didn't correctly take the fact that they were
non-linear into account and added only the skb head portion.
This probably never really triggered, since those frames we want
traced fully are most likely linear anyway, but the code gets easier
to understand and we lose an argument to the tracing function, so
overall fixing this is better.
Fixes: 206eea783385 ("iwlwifi: pcie: support frag SKBs")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
There's no need to calculate the data_len outside of the tracepoint,
since it's always skb->len - hdr_len, which are both available inside.
Simplify the callers and move the calculation in.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Show the name of the member (scanned_channels) that provides the
length with some better markup.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Use kstrtou32_from_user() in debugfs instead of open-coding it.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
On A000 HW, the SCD rdptr has only 8 bits allocated
for it, thus when checking if a queue is full, or
when checking if the SSN is equal to the TID's
next_reclaimed, A000 HW should trim the SSN.
Fix this by "normalizing" the SSN to wrap around
0xFF when comparing to the next_reclaimed on A000
HW.
Signed-off-by: Liad Kaufman <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
We don't actually care about the value at all, just making sure
that we can successfully parse a single integer value, but that's
entirely pointless - remove it.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
When toggling the RF-kill pin quickly in succession, the driver can
get rather confused because it might be in the process of shutting
down, expecting all commands to go through quickly due to rfkill,
but the transport already thinks the device is accessible again,
even though it previously shut it down. This leads to bugs, and I
even observed a kernel panic.
Avoid this by making the PCIe code only report that the radio is
enabled again after the higher layers actually decided to shut it
off.
This also pulls out this common RF-kill checking code into a common
function called by both transport generations and also moves it to
the direct method - in the internal helper we don't really care
about the RF-kill status anymore since we won't report it up until
the stop anyway.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
If we happen to be in or get into the queue sync when RF-kill
is asserted, we return from there and warn since there are
still queue sync notifications outstanding. These can't ever
come though, because we're in RF-kill, so don't WARN then.
While at it, also move the warning to the appropriate place,
if the request is not synchronous then we shouldn't warn, but
currently always will.
To make it fast, also trigger the waitq when on rfkill assert.
Fixes: 0636b938214c ("iwlwifi: mvm: implement driver RX queues sync command")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
In order to debug "hardware" RF-kill flows, add a low-level hook to
allow changing the "hardware" RF-kill from debugfs.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
There's no point in duplicating exactly the same code here
for legacy and MSI-X interrupts, so pull it out into a new
function to call in both places.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
In case that rate's antenna is wrong at the init stage, it's
very hard to say what went wrong. Add debug data to the already
existing WARN_ON_ONCE.
Signed-off-by: Gregory Greenman <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
Some static checkers (e.g. smatch) complain about the logic, saying that
resp_cp might be leaked. Clearly that isn't true, but making the logic
easier to follow does not result in any significant code changes and makes
the code more readable by moving the NULL check closer to its source.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
The firmware moved the development from a0 MAC to z0.
z0 is using the same RFID and device ID as a0 so we only
need to switch the name.
Signed-off-by: Mordechai Goodstein <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
|
|
New FW versions require the D0I3_END_CMD to be sent as the first
command to the FW in the resume flow. If the TLV is set, send that
command first, otherwise keep the original behavior (i.e. send last).
Signed-off-by: Luca Coelho <[email protected]>
|