Kalle Valo [Sun, 30 Jun 2019 09:31:11 +0000 (12:31 +0300)]
Merge tag 'iwlwifi-next-for-kalle-2019-06-29' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Patches intended for v5.3
* Work on the new debugging framework continues;
* Update the FW API for CSI;
* Special SAR implementation for South Korea;
* Fixes in the module init error paths;
* Debugging infra work continues;
* A bunch of RF-kill fixes by Emmanuel;
* A fix for AP mode, also related to RF-kill, by Johannes.
* A few clean-ups;
* Other small fixes and improvements;
Kalle Valo [Sun, 30 Jun 2019 09:29:30 +0000 (12:29 +0300)]
Merge tag 'mt76-for-kvalo-2019-06-27' of https://github.com/nbd168/wireless
mt76 patches for 5.3
* use NAPI polling for tx cleanup on mt7603/mt7615
* various fixes for mt7615
* unify some code between mt7603 and mt7615
* fix locking issues on mt76x02
* add support for toggling edcca on mt7603
* fix reading target tx power with ext PA on mt7603/mt7615
* fix initalizing channel maximum power
* fix rate control / tx status reporting issues on mt76x02/mt7603
* add support for eeprom calibration data from mtd on mt7615
* support configuring tx power on mt7615
* fix external PA support on mt76x0
* per-chain signal reporting on mt7615
* rx/tx buffer fixes for USB devices
Emmanuel Grumbach [Wed, 22 May 2019 09:17:09 +0000 (12:17 +0300)]
iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-Kill
iwl_mvm_send_cmd returns 0 when the command won't be sent
because RF-Kill is asserted. Do the same when we call
iwl_get_shared_mem_conf since it is not sent through
iwl_mvm_send_cmd but directly calls the transport layer.
Emmanuel Grumbach [Tue, 21 May 2019 12:10:38 +0000 (15:10 +0300)]
iwlwifi: pcie: don't service an interrupt that was masked
Sometimes the register status can include interrupts that
were masked. We can, for example, get the RF-Kill bit set
in the interrupt status register although this interrupt
was masked. Then if we get the ALIVE interrupt (for example)
that was not masked, we need to *not* service the RF-Kill
interrupt.
Fix this in the MSI-X interrupt handler.
Emmanuel Grumbach [Mon, 20 May 2019 12:18:24 +0000 (15:18 +0300)]
iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices
Newest devices have a new firmware load mechanism. This
mechanism is called the context info. It means that the
driver doesn't need to load the sections of the firmware.
The driver rather prepares a place in DRAM, with pointers
to the relevant sections of the firmware, and the firmware
loads itself.
At the end of the process, the firmware sends the ALIVE
interrupt. This is different from the previous scheme in
which the driver expected the FH_TX interrupt after each
section being transferred over the DMA.
In order to support this new flow, we enabled all the
interrupts. This broke the assumption that we have in the
code that the RF-Kill interrupt can't interrupt the firmware
load flow.
Change the context info flow to enable only the ALIVE
interrupt, and re-enable all the other interrupts only
after the firmware is alive. Then, we won't see the RF-Kill
interrupt until then. Getting the RF-Kill interrupt while
loading the firmware made us kill the firmware while it is
loading and we ended up dumping garbage instead of the firmware
state.
Re-enable the ALIVE | RX interrupts from the ISR when we
get the ALIVE interrupt to be able to get the RX interrupt
that comes immediately afterwards for the ALIVE
notification. This is needed for non MSI-X only.
We added code to restock the buffer upon ALIVE interrupt
when MSI-X is disabled. This was added as part of the context
info code. This code was added only if the ISR debug level
is set which is very unlikely to be related.
Move this code to run even when the ISR debug level is not
set.
Note that gen2 devices work with MSI-X in most cases so that
this path is seldom used.
Johannes Berg [Mon, 20 May 2019 12:49:56 +0000 (14:49 +0200)]
iwlwifi: mvm: delay GTK setting in FW in AP mode
In AP (and IBSS) mode, we can only set GTKs to firmware after we have
sent down the multicast station, but this we can only do after we've
enabled beaconing, etc.
However, during rfkill exit, hostapd will configure the keys before
starting the AP, and cfg80211/mac80211 accept it happily.
On earlier devices, this didn't bother us as GTK TX wasn't really
handled in firmware, we just put the key material into the TX cmd
and thus it only mattered when we actually transmitted a frame.
On newer devices, however, the firmware needs to track all of this
and that doesn't work if we add the key before the (multicast) sta
it belongs to.
To fix this, keep a list of keys to add during AP enable, and call
the function there.
Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Sun, 19 May 2019 07:32:44 +0000 (10:32 +0300)]
iwlwifi: dbg: debug recording stop and restart command remove
The 0xF6 command used to start and stop the recording from 22560 devices
was removed. This is causing an assert when the driver tries to alter
the recording state.
Remove the use of the command.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Tue, 12 Feb 2019 12:47:08 +0000 (14:47 +0200)]
iwlwifi: dbg_ini: remove redundant checking of ini mode
There are several flows where the driver checks if it runs in ini mode.
Some of these flows are no longer used in ini mode or there is another
condition that check the ini mode in the same flow. Either way, those
conditions are redundant. Remove the redundant conditions.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Thu, 16 May 2019 07:31:17 +0000 (10:31 +0300)]
iwlwifi: dbg: fix debug monitor stop and restart delays
The driver should delay only in recording stop flow between writing to
DBGC_IN_SAMPLE register and DBGC_OUT_CTRL register. Any other delay is
not needed.
Change the following:
1. Remove any unnecessary delays in the flow
2. Increase the delay in the stop recording flow since 100 micro is
not enough
3. Use usleep_range instead of delay since the driver is allowed to
sleep in this flow.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: 5cfe79c8d92a ("iwlwifi: fw: stop and start debugging using host command") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Andrei Otcheretianski [Mon, 15 Apr 2019 13:45:04 +0000 (16:45 +0300)]
iwlwifi: mvm: Drop large non sta frames
In some buggy scenarios we could possible attempt to transmit frames larger
than maximum MSDU size. Since our devices don't know how to handle this,
it may result in asserts, hangs etc.
This can happen, for example, when we receive a large multicast frame
and try to transmit it back to the air in AP mode.
Since in a legal scenario this should never happen, drop such frames and
warn about it.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Haim Dreyfuss [Wed, 27 Feb 2019 14:43:45 +0000 (16:43 +0200)]
iwlwifi: Add support for SAR South Korea limitation
South Korea is adding a more strict SAR limit called "Limb SAR".
Currently, WGDS SAR offset group 3 is not used (not mapped to any country).
In order to be able to comply with South Korea new restriction:
- OEM will use WGDS SAR offset group 3 to South Korea limitation.
- OEM will change WGDS revision to 1 (currently latest revision is 0)
to notify that Korea Limb SAR applied.
- Driver will read the WGDS table and pass the values to FW (as usual)
- Driver will pass to FW an indication that Korea Limb SAR is applied
in case table revision is 1.
Naftali Goldstein [Mon, 13 May 2019 13:36:30 +0000 (16:36 +0300)]
iwlwifi: mvm: correctly fill the ac array in the iwl_mac_ctx_cmd
The indexes into the ac array in the iwl_mac_ctx_cmd are from the iwl_ac
enum and not the txfs. The current code therefore puts the edca params
in the wrong indexes of the array, causing wrong priority for
data-streams of different ACs.
Fix this.
Note that this bug only occurs in NICs that use the new tx api, since in
the old tx api the txf number is equal to the corresponding ac in the
iwl_ac enum.
Gustavo A. R. Silva [Wed, 3 Apr 2019 16:03:42 +0000 (11:03 -0500)]
iwlwifi: d3: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
Gustavo A. R. Silva [Wed, 3 Apr 2019 15:59:01 +0000 (10:59 -0500)]
iwlwifi: lib: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
Mordechay Goodstein [Wed, 1 May 2019 17:48:12 +0000 (20:48 +0300)]
iwlwifi: mvm: remove multiple debugfs entries
Now that we have per station control over amsdu size no need for
multiple entries, especially that the old one is misleading due to not
setting it for all protocols as a limit.
iwlwifi: mvm: add a debugfs entry to set a fixed size AMSDU for all TX packets
The current debugfs entry only limits the max AMSDU for TCP. Add a new
debugfs entry to allow setting a fixed AMSDU size for all TX packets,
including UDP and ICMP
Shahar S Matityahu [Tue, 2 Apr 2019 12:28:46 +0000 (15:28 +0300)]
iwlwifi: dbg_ini: add consecutive trigger firing support
When a dump trigger is fired, the driver sets IWL_FWRT_STATUS_DUMPING and
aborts any consecutive dump collection.
To allow consecutive triggers firing, use 5 dump workers and allocate
them upon incoming dump collection requests.
This functionality is needed since in ini debug mode each trigger may
have entirely different memory regions to collect unlike the legacy
mode in which all the triggers dump the same memory regions.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Mon, 8 Apr 2019 07:57:09 +0000 (10:57 +0300)]
iwlwifi: dbg_ini: dump headers cleanup
Unite dump memory ranges under a single struct and add a specific header
for each type of memory.
Also, maintain a single version to all dump structures.
This cleanup is also needed for the future addition of FW notification
regions and others.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Shahar S Matityahu [Tue, 26 Mar 2019 07:55:37 +0000 (09:55 +0200)]
iwlwifi: dbg: allow dump collection in case of an early error
Improve the robustness of the dump collection flow in case of an early
error:
1. in iwl_trans_pcie_sync_nmi, disable and enable interrupts only if
they were already enabled
2. attempt to initiate dump collection in iwl_fw_dbg_error_collect only
if the device is enabled
3. check Tx command queue was already allocated before trying to collect it
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
iwlwifi: iwl_mvm_tx_mpdu() must be called with BH disabled
As iwl_mvm_tx_mpdu() is not disabling BH while obtaining iwl_mvm_sta->lock
(which is being taken from BH context as well), it has to be always
invoked with BH disabled. Make that clear in a comment.
Zong-Zhe Yang [Wed, 29 May 2019 07:54:46 +0000 (15:54 +0800)]
rtw88: refine flow to get tx power index
Add a structure for power parameters including base,
offset, limit and a function to get tx power parameters.
Then, refine flow to get tx power index through the
function.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Tzu-En Huang [Wed, 29 May 2019 07:54:45 +0000 (15:54 +0800)]
rtw88: remove all RTW_MAX_POWER_INDEX macro
Since this macro definition has different values in different chipset,
the current defined macro value is for 8822b. This will cause the
settings of 8822c be incorrect.
Remove RTW_MAX_POWER_INDEX and use max_power_index in struct rtw_chip_info
to make sure the value of different chipset is right.
Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Zong-Zhe Yang [Wed, 29 May 2019 07:54:44 +0000 (15:54 +0800)]
rtw88: update tx power limit table to RF v20
Support more regulatory domains including IC, KCC,
ACMA, CHILE, UKRAINE, and MEXICO. Corresponding tx
power limits for these regulatory domains are added
in tx power limit table. Besides, tx power limits in
some case are also updated to follow RF v20 for better
tx power indexes.
Channel plan mapping table are upgraded to consider
more 2G and 5G channel plans combination cases. It
allow us to identify different situations more accuratly
by channel plan IDs. In addition, mapping table for
country code and channel plan ID and mapping table
for country code and tx power limit are also updated
to follow RF v20. It allow the new enrties in tx power
limit table to be applied correctly.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Zong-Zhe Yang [Wed, 29 May 2019 07:54:43 +0000 (15:54 +0800)]
rtw88: correct power limit selection
If phy rate is decreased, sub bandwidth may be chosen by RA.
We consider possible power limits and apply the min one;
otherwise, the tx power index may be larger than spec.
And we cross-reference power limits of vht and ht with
20/40M bandwidth in 5G to avoid values are not assigned.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:42 +0000 (15:54 +0800)]
rtw88: choose the lowest as world-wide power limit
When we are loading tx power limit from the power limit table, compare
the world-wide limit with the current limit and choose the lowest power
limit for the world-wide power settings.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:41 +0000 (15:54 +0800)]
rtw88: fix incorrect tx power limit at 5G
Tx power limit is stored separately by 2G and 5G.
But driver did not get tx power limit from 5G and causes incorrect tx
power. Check if the channel is beyond 2G and get the corresponding tx
power limit.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yan-Hsuan Chuang [Wed, 29 May 2019 07:54:39 +0000 (15:54 +0800)]
rtw88: unify prefixes for tx power setting routine
Rename the function names to make them have the same prefix "rtw_phy"
for the tx power setting routines. Only the function names and
corresponding identation are modified.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Step 3:
Apply this semantic patch (coccinelle) to remove the unused 'flags'
variables:
// <smpl>
@@
type T;
identifier i;
@@
(
extern T i;
|
- T i;
... when != i
)
// </smpl>
(Usage is something like this:
make coccicheck COCCI=./patch.cocci MODE=patch M=drivers/net/wireless/marvell/mwifiex/
although this skips *.h files for some reasons, so I had to massage
stuff.)
Testing: I've played with a variety of stress tests, including download
stress tests on the same APs which caught regressions with commit 5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.
Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Brian Norris [Tue, 25 Jun 2019 17:40:44 +0000 (10:40 -0700)]
mwifiex: dispatch/rotate from reorder table atomically
mwifiex_11n_scan_and_dispatch() and
mwifiex_11n_dispatch_pkt_until_start_win() share similar patterns, where
they perform a few different actions on the same table, using the same
lock, but non-atomically. There have been other attempts to clean up
this sort of behavior, but they have had problems (incomplete;
introducing new deadlocks).
We can improve these functions' atomicity by queueing up our RX packets
in a list, to dispatch at the end of the function. This avoids problems
of another operation modifying the table in between our dispatch and
rotation operations.
While the original (now-reverted) patch had good intentions in
restructuring some of the locking patterns in this driver, it missed an
important detail: we cannot defer to softirq contexts while already in
an atomic context. We can help avoid this sort of problem by separating
the two steps of:
(1) iterating / clearing the mwifiex reordering table
(2) dispatching received packets to upper layers
This makes it much harder to make lock recursion mistakes, as these
two steps no longer need to hold the same locks.
Testing: I've played with a variety of stress tests, including download
stress tests on the same APs which caught regressions with commit 5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.
Signed-off-by: Brian Norris <briannorris@chromium.org> Acked-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christoph Hellwig [Tue, 25 Jun 2019 10:29:31 +0000 (12:29 +0200)]
b43: remove b43_dma_set_mask
These days drivers are not required to fallback to smaller DMA masks,
but can just set the largest mask they support, removing the need for
this trial and error logic.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christoph Hellwig [Tue, 25 Jun 2019 10:29:29 +0000 (12:29 +0200)]
b43legacy: remove b43legacy_dma_set_mask
These days drivers are not required to fallback to smaller DMA masks,
but can just set the largest mask they support, removing the need for
this trial and error logic.
Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Lorenzo Bianconi [Thu, 27 Jun 2019 10:13:16 +0000 (12:13 +0200)]
mt76: mt7603: fix sparse warnings: warning: incorrect type in assignment (different base types)
Fix the following sparse warning in mt7603_mcu_set_eeprom:
drivers/net/wireless/mediatek/mt76/mt7603/mcu.c:376:30: sparse: warning:
incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7603/mcu.c:376:30: sparse:
expected unsigned short [usertype] addr
drivers/net/wireless/mediatek/mt76/mt7603/mcu.c:376:30: sparse: got
restricted __le16 [usertype]
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Thu, 27 Jun 2019 09:50:25 +0000 (11:50 +0200)]
mt76: mt7615: fix sparse warnings: warning: cast from restricted __le16
Do not convert {tx,rx}_mcs_map to little-endian since it is already done
by mac80211. This patch fix the following sparse warning:
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:1497:25: sparse:
warning: cast from restricted __le16
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:1499:25: sparse:
warning: cast from restricted __le16
Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Fixes: 3ca0a6f6e9df ("mt7615: mcu: use standard signature for mt7615_mcu_msg_send") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Thu, 27 Jun 2019 08:44:49 +0000 (10:44 +0200)]
mt76: mt7615: fix sparse warnings: incorrect type in assignment (different base types)
Fix the following sparse warning in mt7615_mcu_bss_info_ext_header:
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:728:30: sparse: sparse:
incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:728:30: sparse:
expected restricted __le32 [usertype] mbss_tsf_offset
Reported-by: kbuild test robot <lkp@intel.com> Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Fixes: 7339fbc0caa5 ("mt7615: mcu: do not use function pointers whenever possible") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Thu, 20 Jun 2019 10:39:36 +0000 (12:39 +0200)]
mt76: mt76u: reduce rx memory footprint
Reduce rx memory footprint allocating just one SG buffer since for the
moment we support just 3839B as maximal size of an A-MSDU.
Introduce different SG_MAX_SIZE definitions for TX and RX sides.
Moreover set q->buf_size to PAGE_SIZE even for SG case.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Ryder Lee [Thu, 13 Jun 2019 07:13:30 +0000 (15:13 +0800)]
mt76: mt7615: fix incorrect settings in mesh mode
Fix wrong settings that will drop packets due to hardware's RX table
searching flow.
Fixes: f072c7ba2150 ("mt76: mt7615: enable support for mesh") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Wed, 12 Jun 2019 09:31:15 +0000 (11:31 +0200)]
mt76: mt76x02u: fix sparse warnings: should it be static?
Fix following sparse warnings in mt76x02_usb_core.c
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:29:6: warning:
symbol 'mt76x02u_tx_complete_skb' was not declared. Should it be static?
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:37:5: warning:
symbol 'mt76x02u_skb_dma_info' was not declared. Should it be static?
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:96:52: warning:
restricted __le16 degrades to integer
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:74:5: warning:
symbol 'mt76x02u_tx_prepare_skb' was not declared. Should it be static?
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:244:6: warning:
symbol 'mt76x02u_init_beacon_config' was not declared. Should it be
static?
drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:262:6: warning:
symbol 'mt76x02u_exit_beacon_config' was not declared. Should it be
static?
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 11 Jun 2019 06:38:53 +0000 (08:38 +0200)]
mt76: mt7615: take into account extPA when configuring tx power
When TSSI calibration is disabled (which it means the device has been
equipped with an external power amplifier) we need to refer to
different eeprom fields in order to properly configure tx power
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Move conn_type configuration directly in mt7615_mcu_set_sta_rec and
remove sta_rec_convert_vif_type since it is actually used just in
mt7615_mcu_set_sta_rec
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Now that tx status reporting can figure out the first attempted rate, we can
make switching from lower rates to higher rates more conservative.
This reduces retries under bad link conditions and ensures that fallback
rates get more test coverage
Felix Fietkau [Mon, 24 Jun 2019 22:03:45 +0000 (00:03 +0200)]
mt76: mt7603: rework and fix tx status reporting
Tx status reporting on mt7603 has a number of issues:
- the hardware can alter the first rate index, but it is not reported to
the driver
- probing is very imprecise, because it alters the per-client rate set,
but only considers info->status.rates for rate selection of a single probe
packet
- short/long GI selection has limitations, which are not accurately reported
to mac80211
- if rates are changed while packets are in flight, tx status reports for
the old rate set might be processed based on the new selection
This led to very suboptimal rate selection with minstrel_ht.
This patch completely reworks tx status reporting to get rid of these
limitations:
- Store the previous and current rate set in the driver + the TSF value
at the time of the switch.
- Use the tx status TSF value to determine which rate set needs to be used
as reference.
- Report only short or long GI rates for a single status event, not a mix.
- The hardware reports the last used rate index. Use it along with the
retry count to figure out what rate was used for the first attempt.
- Use the same retry count value for all rate slots to make this calculation
work.
- Derive the probe rate from the current rateset instead of the skb cb
- Do not wait for a status report for the probe frame before removing the
probe rate from the rate table. Do it immediately after it was referenced
in a tx status report.
- Use the first half of the first rate retry budget for the probe rate
in order to avoid using too many retries on that rate
With this patch, throughput under bad link conditions is improved
significantly, and there is a lot less rate fluctuation going on.
Felix Fietkau [Tue, 25 Jun 2019 10:25:25 +0000 (12:25 +0200)]
mt76: mt76x0: fix RF frontend initialization for external PA
When loading EEPROM data from flash, the RF frontend settings need to be
initialized from flash data. Without this, the chip loads the wrong values
from its internal eFuse ROM.
Lorenzo Bianconi [Tue, 4 Jun 2019 22:12:20 +0000 (00:12 +0200)]
mt76: mt7615: remove key check in mt7615_mcu_set_wtbl_key
Do not check key pointer in mt7615_mcu_set_wtbl_key since if set_key_cmd
is SET_KEY, key will be always not NULL. This patch will address a false
positive reported by Coverity-Scan
Addresses-Coverity-ID: 1445463 ("Dereference after null check") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
YueHaibing [Wed, 29 May 2019 14:53:56 +0000 (22:53 +0800)]
mt76: Remove set but not used variables 'pid' and 'final_mpdu'
Fixes gcc '-Wunused-but-set-variable' warnings:
drivers/net/wireless/mediatek/mt76/mt7603/mac.c: In function mt7603_fill_txs:
drivers/net/wireless/mediatek/mt76/mt7603/mac.c:969:5: warning: variable pid set but not used [-Wunused-but-set-variable]
drivers/net/wireless/mediatek/mt76/mt7603/mac.c:961:7: warning: variable final_mpdu set but not used [-Wunused-but-set-variable]
drivers/net/wireless/mediatek/mt76/mt7615/mac.c: In function mt7615_fill_txs:
drivers/net/wireless/mediatek/mt76/mt7615/mac.c:555:5: warning: variable pid set but not used [-Wunused-but-set-variable]
drivers/net/wireless/mediatek/mt76/mt7615/mac.c:552:19: warning: variable final_mpdu set but not used [-Wunused-but-set-variable]
They are never used, so can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Thu, 6 Jun 2019 07:22:15 +0000 (09:22 +0200)]
mt76: mt76x02: fix tx reordering on rate control probing without a-mpdu
To avoid aggregating rate control probing packets with other traffic, and to
ensure that the probing rate gets used, probing packets get assigned a different
internal queueing priority.
This causes packets to be transmitted in a different order, which is compensated
by the receiver side reordering.
However, if A-MPDU is disabled, this reordering can become visible to upper
layers on the receiver side. Disable the priority change if A-MPDU is disabled.
Felix Fietkau [Wed, 5 Jun 2019 18:50:52 +0000 (20:50 +0200)]
mt76: mt76x02: fix tx status reporting issues
When the hardware falls back to lower rates for a transmit attempt, only the
first status report will show the number of retries correctly. The frames
that follow will report the correct final rate, but number of retries set to 0.
This can cause the rate control module to vastly underestimate the number of
retransmissions per rate.
To fix this, we need to keep track of the initial requested tx rate per packet
and pass it to the status information.
For frames with tx status requested, this is simple: use the rate configured
in info->control.rates[0] as reference.
For no-skb tx status information, we have to encode the requested tx rate in
the packet id (and make it possible to distinguish it from real packet ids).
To do that, reduce the packet id field size by one bit, and use that bit to
indicate packet id vs rate.
This change also improves reporting by filling the status rate array with
rates from first rate to final rate, taking the same steps as the hardware
fallback table. This matters in corner cases like MCS8 on HT, where the
fallback target is MCS0, not MCS7.
David S. Miller [Wed, 26 Jun 2019 21:09:33 +0000 (14:09 -0700)]
Merge branch 'macb-build-fixes'
Palmer Dabbelt says:
====================
net: macb: Fix compilation on systems without COMMON_CLK, v2
Our patch to add support for the FU540-C000 broke compilation on at
least powerpc allyesconfig, which was found as part of the linux-next
build regression tests. This must have somehow slipped through the
cracks, as the patch has been reverted in linux-next for a while now.
This patch applies on top of the offending commit, which is the only one
I've even tried it on as I'm not sure how this subsystem makes it to
Linus.
This patch set fixes the issue by adding a dependency of COMMON_CLK to
the MACB Kconfig entry, which avoids the build failure by disabling MACB
on systems where it wouldn't compile. All known users of MACB have
COMMON_CLK, so this shouldn't cause any issues. This is a significantly
simpler approach than disabling just the FU540-C000 support.
I've also included a second patch to indicate this is a driver for a
Cadence device that was originally written by an engineer at Atmel. The
only relation is that I stumbled across it when writing the first patch.
Changes since v1 <20190624061603.1704-1-palmer@sifive.com>:
* Disable MACB on systems without COMMON_CLK, instead of just disabling
the FU540-C000 support on these systems.
* Update the commit message to reflect the driver was written by Atmel.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Palmer Dabbelt [Tue, 25 Jun 2019 08:48:28 +0000 (01:48 -0700)]
net: macb: Kconfig: Rename Atmel to Cadence
The help text makes it look like NET_VENDOR_CADENCE enables support for
Atmel devices, when in reality it's a driver written by Atmel that
supports Cadence devices. This may confuse users that have this device
on a non-Atmel SoC.
The fix is just s/Atmel/Cadence/, but I did go and re-wrap the Kconfig
help text as that change caused it to go over 80 characters.
Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Palmer Dabbelt [Tue, 25 Jun 2019 08:48:27 +0000 (01:48 -0700)]
net: macb: Kconfig: Make MACB depend on COMMON_CLK
commit c218ad559020 ("macb: Add support for SiFive FU540-C000") added a
dependency on the common clock framework to the macb driver, but didn't
express that dependency in Kconfig. As a result macb now fails to
compile on systems without COMMON_CLK, which specifically causes a build
failure on powerpc allyesconfig.
This patch adds the dependency, which results in the macb driver no
longer being selectable on systems without the common clock framework.
All known systems that have this device already support the common clock
framework, so this should not cause trouble for any uses. Supporting
both the FU540-C000 and systems without COMMON_CLK is quite ugly.
I've build tested this on powerpc allyesconfig and RISC-V defconfig
(which selects MACB), but I have not even booted the resulting kernels.
Fixes: c218ad559020 ("macb: Add support for SiFive FU540-C000") Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dave Taht [Sat, 22 Jun 2019 17:07:34 +0000 (10:07 -0700)]
Allow 0.0.0.0/8 as a valid address range
The longstanding prohibition against using 0.0.0.0/8 dates back
to two issues with the early internet.
There was an interoperability problem with BSD 4.2 in 1984, fixed in
BSD 4.3 in 1986. BSD 4.2 has long since been retired.
Secondly, addresses of the form 0.x.y.z were initially defined only as
a source address in an ICMP datagram, indicating "node number x.y.z on
this IPv4 network", by nodes that know their address on their local
network, but do not yet know their network prefix, in RFC0792 (page
19). This usage of 0.x.y.z was later repealed in RFC1122 (section
3.2.2.7), because the original ICMP-based mechanism for learning the
network prefix was unworkable on many networks such as Ethernet (which
have longer addresses that would not fit into the 24 "node number"
bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951)
or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask
(and other parameters such as default gateways). 0.x.y.z has had
16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for
future use, since 1989.
This patch allows for these 16m new IPv4 addresses to appear within
a box or on the wire. Layer 2 switches don't care.
0.0.0.0/32 is still prohibited, of course.
Signed-off-by: Dave Taht <dave.taht@gmail.com> Signed-off-by: John Gilmore <gnu@toad.com> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Fri, 21 Jun 2019 23:27:16 +0000 (16:27 -0700)]
rtnetlink: skip metrics loop for dst_default_metrics
dst_default_metrics has all of the metrics initialized to 0, so nothing
will be added to the skb in rtnetlink_put_metrics. Avoid the loop if
metrics is from dst_default_metrics.
Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 26 Jun 2019 20:05:42 +0000 (13:05 -0700)]
Merge branch 'skfp-cleanups'
Puranjay Mohan says:
====================
net: fddi: skfp: Use PCI generic definitions instead of private duplicates
This patch series removes the private duplicates of PCI definitions in
favour of generic definitions defined in pci_regs.h.
This driver only uses some of the generic PCI definitons,
which are included from pci_regs.h and thier private versions
are removed from skfbi.h with all other private defines.
The skfbi.h defines PCI_REV_ID and other private defines with different
names, these are renamed to Generic PCI names to make them
compatible with defines in pci_regs.h.
All unused defines are removed from skfbi.h.
Changes in v5:
Removed unused PCI definitions which were left in v4
Changes in v4:
Removed unused PCI definitions which were left in v3
Changes in v3:
Renamed all local PCI definitions to Generic names.
Corrected coding style mistakes.
Changes in v2:
Converted individual patches to a series.
Made sure that individual patches build correctly
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Wed, 26 Jun 2019 17:12:17 +0000 (10:12 -0700)]
Merge tag 'wireless-drivers-next-for-davem-2019-06-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valu says:
====================
wireless-drivers-next patches for 5.3
First set of patches for 5.3, but not that many patches this time.
This pull request fails to compile with the tip tree due to
ktime_get_boot_ns() API changes there. It should be easy for Linus to
fix it in p54 driver once he pulls this, an example resolution here:
projects / linux.git / log