* [PATCH v4 0/2] Add support for new channels on 60GHz band
From: Alexei Avshalom Lazar @ 2019-07-07 14:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: Alexei Avshalom Lazar, linux-wireless, wil6210
The following set of patches add support for new channels on
60GHz band and EDMG channels:
Changelog:
V4:
- Addressed to comments from the community
- Updated comments and variable name
V3:
- Addressed to comments from the community
- Added 60G check for verifying some EDMG cases are relevant
- Used the ieee80211_sta_edmg_cap struct as the edmg channel configuration
- Updated nla_policy to NLA_POLICY_RANGE()
V2
- Addressed to comments from the community
- Align to latest Spec release
Alexei Avshalom Lazar (2):
nl80211: Add support for EDMG channels
wil6210: Add EDMG channel support
drivers/net/wireless/ath/wil6210/cfg80211.c | 205 +++++++++++++++++++++++++--
drivers/net/wireless/ath/wil6210/txrx_edma.c | 2 +
drivers/net/wireless/ath/wil6210/txrx_edma.h | 6 +
drivers/net/wireless/ath/wil6210/wil6210.h | 8 +-
drivers/net/wireless/ath/wil6210/wmi.c | 5 +-
drivers/net/wireless/ath/wil6210/wmi.h | 30 +++-
include/net/cfg80211.h | 37 ++++-
include/uapi/linux/nl80211.h | 22 +++
net/wireless/chan.c | 158 ++++++++++++++++++++-
net/wireless/nl80211.c | 35 +++++
net/wireless/util.c | 42 +++++-
11 files changed, 530 insertions(+), 20 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v3 1/2] nl80211: Add support for EDMG channels
From: Alexei Lazar @ 2019-07-07 14:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wil6210
In-Reply-To: <77b693b163faf61d72b2734b97081734f0345211.camel@sipsolutions.net>
On 2019-06-28 16:21, Johannes Berg wrote:
> On Tue, 2019-06-25 at 13:29 +0300, Alexei Avshalom Lazar wrote:
Hi Johannes,
Again, Thank you for the review, comments inline.
Thanks,
Alex.
>>
>> /**
>> + * struct ieee80211_sta_edmg_cap - EDMG capabilities
>> + *
>> + * This structure describes most essential parameters needed
>> + * to describe 802.11ay EDMG capabilities
>> + *
>> + * @channels: bitmap that indicates the 2.16 GHz channel(s)
>> + * that are allowed to be used for transmissions.
>> + * Bit 0 indicates channel 1, bit 1 indicates channel 2, etc.
>> + * Set to 0 indicate EDMG not supported.
>> + * @bw_config: Channel BW Configuration subfield encodes
>> + * the allowed channel bandwidth configurations
>> + */
>> +struct ieee80211_sta_edmg_cap {
>> + u8 channels;
>> + u8 bw_config;
>> +};
>
> [...]
>
>> + * @edmg: define the EDMG channels configuration.
>> + * If edmg is set, chan will define the primary channel and all other
>> + * parameters are ignored.
>>
>> struct cfg80211_chan_def {
>
> Thinking out loud, maybe this should say "If edmg is requested (i.e.
> the
> .channels member is non-zero) [...]" or so?
Done.
>
>> @@ -1192,6 +1218,7 @@ enum rate_info_bw {
>> * @he_dcm: HE DCM value
>> * @he_ru_alloc: HE RU allocation (from &enum nl80211_he_ru_alloc,
>> * only valid if bw is %RATE_INFO_BW_HE_RU)
>> + * @n_bonded_ch: In case of EDMG the number of bonded channels (1-4)
>
> So, just for the stupid me because I didn't really read the spec.
>
> You have N channels (can only be 8 since you use a u8, looking at the
> code further it looks like there are only 7) and edmg_cap::channels
> indicates which are supported/requested, and then edmg_cap::bw_config
> indicates how the channels are used?
>
> I'm not sure I understand this part, because if you, say, request
> channels 1 and 2 (channels=0x3) then what configurations could be
> possible below that?
>
> Oh, something about the primary channel maybe?
>
>
> I guess I would've expected something like a list of bitmaps that the
> device supports, and then at runtime you select only one bitmap.
>
> If I have channels 1 and 2 enabled, how do the configurations differ?
>
> Clearly they don't differ enough to make capturing them in the rate
> worthwhile, here n_bonded_ch would presumably only be 2, and that's
> enough to tell the rate. What then does the configuration mean?
Channels is a bitmap of 2.16GHz (normal) channels 1..6
bw_config defines the allowed combinations (bonding) of these "normal"
channels.
Let's say driver reports support for channels number 1,2,3
(channels=0x7).
Example #1: driver reports bw_config=5
bw_config=5 allows combinations of 1 or 2 channels.
It means driver can operate in one of these combinations:
Channel 1 only
Channel 2 only
Channel 3 only
Channels 1+2 (cb2)
Channels 2+3 (cb2)
Example #2: driver reports bw_config=10
bw_config=10 allows combinations of 1,2 or 3 channels.
It means driver can operate in one of these combinations:
Channel 1 only
Channel 2 only
Channel 3 only
Channels 1+2 (cb2)
Channels 2+3 (cb2)
Channels 1+3 (cb2) - note 1 & 3 are non-contiguous channels, This
combination
is not allow in bw_config=5
Channels 1+2+3 (cb3)
The primary channel BTW must be one of the operational channels so if
driver choose channels 1+3 then primary channel cannot be 2.
>
>
> It seems to me that you should, however, expose n_bonded_ch to
> userspace? We do expose all the details about the bitrate normally, see
> nl80211_put_sta_rate(). We do calculate the bitrate to expose that too,
> but do expose all the details too.
>
> Hmm. Looking at that, it looks like DMG doesn't actually do that. So
> perhaps not, though it seems to me that it ought to be possible?
We will look into that and address in separate patch.
>
>> @@ -2436,6 +2467,7 @@ struct cfg80211_connect_params {
>> const u8 *fils_erp_rrk;
>> size_t fils_erp_rrk_len;
>> bool want_1x;
>> + struct ieee80211_sta_edmg_cap edmg;
>
> Maybe we really should rename this struct type? It's not a "capability"
> here.
Done.
>
>> +static bool cfg80211_edmg_chandef_valid(const struct
>> cfg80211_chan_def *chandef)
>> +{
>> + int max_continuous = 0;
>> + int num_of_enabled = 0;
>> + int contiguous = 0;
>
> max_continuous vs. contiguous is even more confusing now :-)
>
>
>> + max_continuous = max(contiguous, max_continuous);
>
> See? :)
Done.
>
>> + /* basic verification of edmg configuration according to
>> + * IEEE802.11 section 9.4.2.251
>
> All the IEEE 802.11 references (more than just this one) ... please
> qualify them with a version. I'm thinking these are not in -2016, so
> probably 802.11ay (perhaps even draft?)
Done.
>
>> + */
>> + /* check bw_config against contiguous edmg channels */
>> + switch (chandef->edmg.bw_config) {
>> + case 4:
>> + case 8:
>> + case 12:
>> + if (max_continuous < 1)
>> + return false;
>> + break;
>
> I guess I really should try to find a copy of the appropriate spec ...
>
> johannes
--
Alexei Lazar
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum a
Linux Foundation Collaborative Project
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2019-07-06
From: David Miller @ 2019-07-06 22:20 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <878stbabkb.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Sat, 06 Jul 2019 10:04:20 +0300
> here's a pull request to net-next tree for v5.3, more info below. I will
> be offline from Sunday to Thursday, but Johannes should be able to help
> during that time.
Pulled, thanks Kalle.
^ permalink raw reply
* pull-request: wireless-drivers-next 2019-07-06
From: Kalle Valo @ 2019-07-06 7:04 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next tree for v5.3, more info below. I will
be offline from Sunday to Thursday, but Johannes should be able to help
during that time.
Kalle
The following changes since commit 8b89d8dad5df177032e7e97ecfb18f01134e0e4b:
Merge branch 'macb-build-fixes' (2019-06-26 14:09:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-07-06
for you to fetch changes up to 5adcdab6ae1b0a53456e8a269b1856094dc20a59:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2019-07-01 22:23:11 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 5.3
Second, and last, set of patches for 5.3.
Major changes:
mt76
* use NAPI polling for tx cleanup on mt7603/mt7615
* add support for toggling edcca on mt7603
* 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
* per-chain signal reporting on mt7615
iwlwifi
* Update the FW API for Channel State Information (CSI)
* Special Specific Absorption Rate (SAR) implementation for South Korea
ath10k
* fixes for SDIO support
* add support for firmware logging via WMI
----------------------------------------------------------------
Ahmad Masri (4):
wil6210: enlarge Tx status ring size
wil6210: increase the frequency of status ring hw tail update
wil6210: set WIL_WMI_CALL_GENERAL_TO_MS as wmi_call timeout
wil6210: drop old event after wmi_call timeout
Alexei Avshalom Lazar (3):
wil6210: do not reset FW in STA to P2P client interface switch
wil6210: Add support for setting RBUFCAP configuration
wil6210: update cid boundary check of wil_find_cid/_by_idx()
Andrei Otcheretianski (1):
iwlwifi: mvm: Drop large non sta frames
Ashok Raj Nagarajan (1):
ath10k: add support for controlling tx power to a station
Balaji Pothunoori (1):
ath10k: enabling tx stats support over pktlog
Brian Norris (2):
mwifiex: dispatch/rotate from reorder table atomically
mwifiex: don't disable hardirqs; just softirqs
Christian Lamparter (2):
carl9170: fix misuse of device driver API
carl9170: remove dead branch in op_conf_tx callback
Christoph Hellwig (4):
b43legacy: remove b43legacy_dma_set_mask
b43legacy: simplify engine type / DMA mask selection
b43: remove b43_dma_set_mask
b43: simplify engine type / DMA mask selection
Claire Chang (2):
ath10k: acquire lock to fix lockdep's warning
ath10k: add missing error handling
Dan Carpenter (3):
mt76: Fix a signedness bug in mt7615_add_interface()
mt76: mt7615: Use after free in mt7615_mcu_set_bcn()
iwlwifi: remove some unnecessary NULL checks
Dedy Lansky (1):
wil6210: fix printout in wil_read_pmccfg
Dundi Raviteja (2):
ath10k: Add peer delete response event
ath10k: Fix memory leak in qmi
Emmanuel Grumbach (7):
iwlwifi: support FSEQ TLV even when FMAC is not compiled
iwlwifi: mvm: make the usage of TWT configurable
iwlwifi: pcie: fix ALIVE interrupt handling for gen2 devices w/o MSI-X
iwlwifi: fix RF-Kill interrupt while FW load for gen2 devices
iwlwifi: pcie: don't service an interrupt that was masked
iwlwifi: don't WARN when calling iwl_get_shared_mem_conf with RF-Kill
iwlwifi: mvm: clear rfkill_safe_init_done when we start the firmware
Erik Stromdahl (2):
ath10k: add inline wrapper for htt_h2t_aggr_cfg_msg
ath10k: add htt_h2t_aggr_cfg_msg op for high latency devices
Fabio Estevam (1):
ath10k: Change the warning message string
Felix Fietkau (7):
mt76: mt7603: fix reading target tx power from eeprom
mt76: fix setting chan->max_power
mt76: mt76x02: fix tx status reporting issues
mt76: mt76x02: fix tx reordering on rate control probing without a-mpdu
mt76: mt76x0: fix RF frontend initialization for external PA
mt76: mt7603: rework and fix tx status reporting
mt76: mt7603: improve hardware rate switching configuration
Govind Singh (1):
ath10k: Add WMI diag fw logging support for WCN3990
Greg Kroah-Hartman (1):
wil6210: no need to check return value of debugfs_create functions
Gustavo A. R. Silva (2):
iwlwifi: lib: Use struct_size() helper
iwlwifi: d3: Use struct_size() helper
Haim Dreyfuss (2):
iwlwifi: Add support for SAR South Korea limitation
iwlwifi: mvm: Add log information about SAR status
Jiri Kosina (1):
iwlwifi: iwl_mvm_tx_mpdu() must be called with BH disabled
Johannes Berg (3):
iwlwifi: update CSI API
iwlwifi: fix module init error paths
iwlwifi: mvm: delay GTK setting in FW in AP mode
Kalle Valo (5):
ath10k: remove unnecessary 'out of memory' message
ath10k: pci: remove unnecessary casts
Merge tag 'mt76-for-kvalo-2019-06-27' of https://github.com/nbd168/wireless
Merge tag 'iwlwifi-next-for-kalle-2019-06-29' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Lorenzo Bianconi (53):
mt76: mt76x02: remove useless return in mt76x02_resync_beacon_timer
mt76: move tx_napi in mt76_dev
mt76: mt7603: use napi polling for tx cleanup
mt76: mt7615: use napi polling for tx cleanup
mt76: move netif_napi_del in mt76_dma_cleanup
mt7615: mcu: simplify __mt7615_mcu_set_wtbl
mt7615: mcu: simplify __mt7615_mcu_set_sta_rec
mt7615: mcu: remove bss_info_convert_vif_type routine
mt7615: mcu: use proper msg size in mt7615_mcu_add_wtbl_bmc
mt7615: mcu: use proper msg size in mt7615_mcu_add_wtbl
mt7615: mcu: unify mt7615_mcu_add_wtbl_bmc and mt7615_mcu_del_wtbl_bmc
mt7615: mcu: remove unused parameter in mt7615_mcu_del_wtbl
mt7615: remove query from mt7615_mcu_msg_send signature
mt7615: remove dest from mt7615_mcu_msg_send signature
mt7615: mcu: remove skb_ret from mt7615_mcu_msg_send
mt7615: mcu: unify __mt7615_mcu_set_dev_info and mt7615_mcu_set_dev_info
mt7615: mcu: do not use function pointers whenever possible
mt7615: mcu: remove unused structure in mcu.h
mt7615: mcu: use standard signature for mt7615_mcu_msg_send
mt7615: initialize mt76_mcu_ops data structure
mt7615: mcu: init mcu_restart function pointer
mt7615: mcu: run __mt76_mcu_send_msg in mt7615_mcu_send_firmware
mt76: mt7603: stop mac80211 queues before setting the channel
mt76: mt7615: rearrange cleanup operations in mt7615_unregister_device
mt76: mt7615: add static qualifier to mt7615_rx_poll_complete
mt76: mt76x02: remove enable from mt76x02_edcca_init signature
mt76: mt76x2u: remove mt76x02_edcca_init in mt76x2u_set_channel
mt76: mt76x2: move mutex_lock inside mt76x2_set_channel
mt76: mt76x02: run mt76x02_edcca_init atomically in mt76_edcca_set
mt76: mt7603: add debugfs knob to enable/disable edcca
mt76: mt76x02: fix edcca file permission
mt76: mt7615: do not process rx packets if the device is not initialized
mt76: move mt76_insert_ccmp_hdr in mt76-module
mt76: mt7615: add support for mtd eeprom parsing
mt76: mt7615: select wifi band according to eeprom
mt76: generalize mt76_get_txpower for 4x4:4 devices
mt76: mt7615: add the capability to configure tx power
mt76: mt7615: init get_txpower mac80211 callback
mt76: mt7615: rearrange locking in mt7615_config
mt76: move mt76_get_rate in mt76-module
mt76: mt7615: remove unused variable in mt7615_mcu_set_bcn
mt76: mt7615: remove key check in mt7615_mcu_set_wtbl_key
mt76: mt7615: simplify mt7615_mcu_set_sta_rec routine
mt76: mt7615: init per-channel target power
mt76: mt7615: take into account extPA when configuring tx power
mt76: mt76x02u: fix sparse warnings: should it be static?
mt76: mt76u: reduce rx memory footprint
mt76: mt7615: remove cfg80211_chan_def from mt7615_set_channel signature
mt76: move nl80211_dfs_regions in mt76_dev data structure
mt76: mt76u: get rid of {out,in}_max_packet
mt76: mt7615: fix sparse warnings: incorrect type in assignment (different base types)
mt76: mt7615: fix sparse warnings: warning: cast from restricted __le16
mt76: mt7603: fix sparse warnings: warning: incorrect type in assignment (different base types)
Luca Coelho (2):
iwlwifi: pcie: increase the size of PCI dumps
iwlwifi: mvm: remove MAC_FILTER_IN_11AX for AP mode
Maya Erez (2):
wil6210: clear FW and ucode log address
wil6210: publish max_msdu_size to FW on BCAST ring
Miaoqing Pan (3):
ath10k: fix fw crash by moving chip reset after napi disabled
ath10k: fix failure to set multiple fixed rate
ath10k: fix PCIE device wake up failed
Mordechay Goodstein (2):
iwlwifi: mvm: add a debugfs entry to set a fixed size AMSDU for all TX packets
iwlwifi: mvm: remove multiple debugfs entries
Naftali Goldstein (1):
iwlwifi: mvm: correctly fill the ac array in the iwl_mac_ctx_cmd
Rakesh Pillai (1):
ath10k: wait for vdev delete response from firmware
Ryder Lee (5):
mt76: mt7615: enable support for mesh
mt76: mt7615: fix slow performance when enable encryption
mt76: mt7615: add support for per-chain signal strength reporting
mt76: mt7615: fix incorrect settings in mesh mode
mt76: mt7615: update peer's bssid when state transition occurs
Shahar S Matityahu (15):
iwlwifi: dbg: allow dump collection in case of an early error
iwlwifi: dbg_ini: dump headers cleanup
iwlwifi: dbg_ini: abort region collection in case the size is 0
iwlwifi: dbg_ini: add consecutive trigger firing support
iwlwifi: dbg_ini: use different barker for ini dump
iwlwifi: dbg_ini: support debug info TLV
iwlwifi: dbg_ini: implement dump info collection
iwlwifi: fw api: support adwell HB default APs number api
iwlwifi: dbg: fix debug monitor stop and restart delays
iwlwifi: dbg_ini: enforce apply point early on buffer allocation tlv
iwlwifi: dbg_ini: remove redundant checking of ini mode
iwlwifi: dbg: move trans debug fields to a separate struct
iwlwifi: dbg_ini: fix debug monitor stop and restart in ini mode
iwlwifi: dbg: don't stop dbg recording before entering D3 from 9000 devices
iwlwifi: dbg: debug recording stop and restart command remove
Shaul Triebitz (1):
iwlwifi: mvm: convert to FW AC when configuring MU EDCA
Tzahi Sabo (1):
wil6210: add support for reading multiple RFs temperature via debugfs
Tzu-En Huang (1):
rtw88: remove all RTW_MAX_POWER_INDEX macro
Venkateswara Naralasetty (1):
ath10k: Add wrapper function to ath10k debug
Wen Gong (6):
ath10k: add support for firmware crash recovery on SDIO chip
ath10k: change firmware file name for UTF mode of SDIO/USB
ath10k: add report MIC error for sdio chip
ath10k: add new hw_ops for sdio chip
ath10k: Move non-fatal warn logs to dbg level for SDIO chip
ath10k: destroy sdio workqueue while remove sdio module
Yan-Hsuan Chuang (6):
rtw88: resolve order of tx power setting routines
rtw88: do not use (void *) as argument
rtw88: unify prefixes for tx power setting routine
rtw88: remove unused variable
rtw88: fix incorrect tx power limit at 5G
rtw88: choose the lowest as world-wide power limit
YueHaibing (2):
mt76: mt7615: Make mt7615_irq_handler static
mt76: Remove set but not used variables 'pid' and 'final_mpdu'
Zefir Kurtisi (1):
ath9k: correctly handle short radar pulses
Zong-Zhe Yang (3):
rtw88: correct power limit selection
rtw88: update tx power limit table to RF v20
rtw88: refine flow to get tx power index
drivers/net/wireless/ath/ath10k/core.c | 34 +-
drivers/net/wireless/ath/ath10k/core.h | 15 +-
drivers/net/wireless/ath/ath10k/debug.c | 8 +-
drivers/net/wireless/ath/ath10k/debug.h | 25 +-
drivers/net/wireless/ath/ath10k/hif.h | 15 +
drivers/net/wireless/ath/ath10k/htt.c | 2 +-
drivers/net/wireless/ath/ath10k/htt.h | 16 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 20 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 9 +-
drivers/net/wireless/ath/ath10k/hw.c | 6 +-
drivers/net/wireless/ath/ath10k/hw.h | 7 +
drivers/net/wireless/ath/ath10k/mac.c | 209 +++-
drivers/net/wireless/ath/ath10k/pci.c | 25 +-
drivers/net/wireless/ath/ath10k/qmi.c | 46 +
drivers/net/wireless/ath/ath10k/qmi.h | 1 +
drivers/net/wireless/ath/ath10k/sdio.c | 17 +-
drivers/net/wireless/ath/ath10k/snoc.c | 15 +
drivers/net/wireless/ath/ath10k/swap.c | 4 +-
drivers/net/wireless/ath/ath10k/testmode.c | 17 +-
drivers/net/wireless/ath/ath10k/trace.c | 1 +
drivers/net/wireless/ath/ath10k/trace.h | 6 +-
drivers/net/wireless/ath/ath10k/usb.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 33 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 8 +-
drivers/net/wireless/ath/ath10k/wmi.h | 16 +-
drivers/net/wireless/ath/ath9k/recv.c | 6 +-
drivers/net/wireless/ath/carl9170/main.c | 9 +-
drivers/net/wireless/ath/carl9170/usb.c | 39 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 22 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 168 +--
drivers/net/wireless/ath/wil6210/main.c | 19 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 1 +
drivers/net/wireless/ath/wil6210/rx_reorder.c | 31 +-
drivers/net/wireless/ath/wil6210/txrx.c | 9 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 16 +-
drivers/net/wireless/ath/wil6210/txrx_edma.h | 2 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 6 +
drivers/net/wireless/ath/wil6210/wmi.c | 127 +-
drivers/net/wireless/ath/wil6210/wmi.h | 47 +-
drivers/net/wireless/broadcom/b43/dma.c | 69 +-
drivers/net/wireless/broadcom/b43legacy/dma.c | 57 +-
drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 3 +-
drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 28 +-
drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 5 +-
.../net/wireless/intel/iwlwifi/fw/api/dbg-tlv.h | 22 +
.../net/wireless/intel/iwlwifi/fw/api/location.h | 11 +-
drivers/net/wireless/intel/iwlwifi/fw/api/power.h | 12 +
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 15 +
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 427 ++++---
drivers/net/wireless/intel/iwlwifi/fw/dbg.h | 133 +-
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 111 +-
drivers/net/wireless/intel/iwlwifi/fw/file.h | 17 +-
drivers/net/wireless/intel/iwlwifi/fw/init.c | 7 +-
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 28 +-
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 12 +-
drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 33 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 35 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 75 +-
drivers/net/wireless/intel/iwlwifi/mvm/constants.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 14 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 66 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 72 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 16 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 66 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 9 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 26 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 25 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 16 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 20 +-
.../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 10 +-
.../net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 29 +-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 68 +-
.../net/wireless/intel/iwlwifi/pcie/trans-gen2.c | 11 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 187 +--
drivers/net/wireless/marvell/mwifiex/11n.c | 53 +-
drivers/net/wireless/marvell/mwifiex/11n.h | 5 +-
drivers/net/wireless/marvell/mwifiex/11n_aggr.c | 26 +-
drivers/net/wireless/marvell/mwifiex/11n_aggr.h | 2 +-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 125 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 35 +-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 76 +-
drivers/net/wireless/marvell/mwifiex/init.c | 32 +-
drivers/net/wireless/marvell/mwifiex/main.c | 29 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 58 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 5 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 10 +-
drivers/net/wireless/marvell/mwifiex/tdls.c | 68 +-
drivers/net/wireless/marvell/mwifiex/txrx.c | 5 +-
drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 10 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 10 +-
drivers/net/wireless/marvell/mwifiex/util.c | 15 +-
drivers/net/wireless/marvell/mwifiex/wmm.c | 109 +-
drivers/net/wireless/mediatek/mt76/dma.c | 1 +
drivers/net/wireless/mediatek/mt76/mac80211.c | 62 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 23 +-
drivers/net/wireless/mediatek/mt76/mt7603/core.c | 2 +-
.../net/wireless/mediatek/mt76/mt7603/debugfs.c | 30 +
drivers/net/wireless/mediatek/mt76/mt7603/dma.c | 29 +-
drivers/net/wireless/mediatek/mt76/mt7603/eeprom.h | 2 +
drivers/net/wireless/mediatek/mt76/mt7603/init.c | 26 +-
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 191 +--
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 8 +-
drivers/net/wireless/mediatek/mt76/mt7603/mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h | 15 +-
drivers/net/wireless/mediatek/mt76/mt7603/regs.h | 6 +
drivers/net/wireless/mediatek/mt76/mt7615/dma.c | 23 +-
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 97 +-
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.h | 61 +
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 77 +-
drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 85 +-
drivers/net/wireless/mediatek/mt76/mt7615/mac.h | 5 +
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 52 +-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 1265 ++++++++++---------
drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 56 +-
drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h | 16 +-
drivers/net/wireless/mediatek/mt76/mt7615/pci.c | 7 +-
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 5 +-
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 13 +-
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02.h | 1 -
.../net/wireless/mediatek/mt76/mt76x02_beacon.c | 4 +-
.../net/wireless/mediatek/mt76/mt76x02_debugfs.c | 10 +-
drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c | 18 +-
drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h | 2 -
.../net/wireless/mediatek/mt76/mt76x02_eeprom.h | 1 +
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 106 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mac.h | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 18 +-
drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 3 +
drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c | 9 +-
.../net/wireless/mediatek/mt76/mt76x02_usb_core.c | 11 +-
drivers/net/wireless/mediatek/mt76/mt76x2/init.c | 9 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_main.c | 16 +-
.../net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 8 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_init.c | 2 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_main.c | 23 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_phy.c | 7 +-
drivers/net/wireless/mediatek/mt76/usb.c | 20 +-
drivers/net/wireless/realtek/rtw88/main.c | 26 +-
drivers/net/wireless/realtek/rtw88/main.h | 27 +-
drivers/net/wireless/realtek/rtw88/phy.c | 1298 +++++++++++---------
drivers/net/wireless/realtek/rtw88/phy.h | 18 +-
drivers/net/wireless/realtek/rtw88/regd.c | 69 +-
drivers/net/wireless/realtek/rtw88/regd.h | 4 +
.../net/wireless/realtek/rtw88/rtw8822c_table.c | 799 +++++++++++-
150 files changed, 5196 insertions(+), 2976 deletions(-)
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Larry Finger @ 2019-07-05 23:26 UTC (permalink / raw)
To: Daniel Drake, Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAD8Lp44HLPgOU+Z+w4Pq6ukLjZv2hM0=uBL7pWzQp+RsdRgG6Q@mail.gmail.com>
On 7/4/19 10:44 PM, Daniel Drake wrote:
> On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>> My point is this seems to be very dongle dependent :( We have to be
>> careful not breaking it for some users while fixing it for others.
>
> Do you still have your device?
>
> Once we get to the point when you are happy with Chris's two patches
> here on a code review level, we'll reach out to other driver
> contributors plus people who previously complained about these types
> of problems, and see if we can get some wider testing.
>
> Larry, do you have these devices, can you help with testing too?
I have some of the devices, and I can help with the testing.
Larry
^ permalink raw reply
* [PATCH] mt76: mt76x0u: add support to TP-Link T2UHP
From: Lorenzo Bianconi @ 2019-07-05 19:01 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, sidhayn, sgruszka
Introduce support to TP-Link T2UHP
https://wikidevi.com/wiki/TP-LINK_Archer_T2UHP
Tested-by: Sid Hayn <sidhayn@gmail.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
index 627ed1fc7b15..b007bcd2e999 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
@@ -32,6 +32,7 @@ static struct usb_device_id mt76x0_device_table[] = {
{ USB_DEVICE(0x20f4, 0x806b) }, /* TRENDnet TEW-806UBH */
{ USB_DEVICE(0x7392, 0xc711) }, /* Devolo Wifi ac Stick */
{ USB_DEVICE(0x0df6, 0x0079) }, /* Sitecom Europe B.V. ac Stick */
+ { USB_DEVICE(0x2357, 0x0123) }, /* TP-LINK T2UHP */
{ USB_DEVICE(0x2357, 0x0105),
.driver_info = 1, }, /* TP-LINK Archer T1U */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7630, 0xff, 0x2, 0xff)}, /* MT7630U */
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Jes Sorensen @ 2019-07-05 18:27 UTC (permalink / raw)
To: Daniel Drake
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAD8Lp44HLPgOU+Z+w4Pq6ukLjZv2hM0=uBL7pWzQp+RsdRgG6Q@mail.gmail.com>
On 7/4/19 11:44 PM, Daniel Drake wrote:
> On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>> My point is this seems to be very dongle dependent :( We have to be
>> careful not breaking it for some users while fixing it for others.
>
> Do you still have your device?
>
> Once we get to the point when you are happy with Chris's two patches
> here on a code review level, we'll reach out to other driver
> contributors plus people who previously complained about these types
> of problems, and see if we can get some wider testing.
I should have them, but I won't have access to them for another 2.5
weeks unfortunately.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Jes Sorensen @ 2019-07-05 18:24 UTC (permalink / raw)
To: Chris Chiu
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <CAB4CAwc8jJQ2f8vpoB0Y6sc0fJmmrq+5rRuJ+TqGMMgCczRi+A@mail.gmail.com>
On 7/4/19 10:27 PM, Chris Chiu wrote:
> On Fri, Jul 5, 2019 at 12:43 AM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>>
>> On 7/4/19 6:55 AM, Chris Chiu wrote:
>>> The WiFi tx power of RTL8723BU is extremely low after booting. So
>>> the WiFi scan gives very limited AP list and it always fails to
>>> connect to the selected AP. This module only supports 1x1 antenna
>>> and the antenna is switched to bluetooth due to some incorrect
>>> register settings.
>>>
>>> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
>>> we realized that the 8723bu's enable_rf() does the same thing as
>>> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
>>> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
>>> the cause of the wifi weak tx power. The vendor driver will set
>>> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
>>> mechanism, by the function halbtc8723b1ant_PsTdma.
>>>
>>> This commit hand over the antenna control to PTA(Packet Traffic
>>> Arbitration), which compares the weight of bluetooth/wifi traffic
>>> then determine whether to continue current wifi traffic or not.
>>> After PTA take control, The wifi signal will be back to normal and
>>> the bluetooth scan can also work at the same time. However, the
>>> btcoexist still needs to be handled under different circumstances.
>>> If there's a BT connection established, the wifi still fails to
>>> connect until BT disconnected.
>>>
>>> Signed-off-by: Chris Chiu <chiu@endlessm.com>
>>> ---
>>>
>>>
>>> Note:
>>> v2:
>>> - Replace BIT(11) with the descriptive definition
>>> - Meaningful comment for the REG_S0S1_PATH_SWITCH setting
>>>
>>>
>>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 11 ++++++++---
>>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
>>> 2 files changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
>>> index 3adb1d3d47ac..ceffe05bd65b 100644
>>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
>>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
>>> @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
>>> /*
>>> * WLAN action by PTA
>>> */
>>> - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
>>> + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
>>>
>>> /*
>>> * BT select S0/S1 controlled by WiFi
>>> @@ -1568,9 +1568,14 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
>>> rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
>>>
>>> /*
>>> - * 0x280, 0x00, 0x200, 0x80 - not clear
>>> + * Different settings per different antenna position.
>>> + * Antenna Position: | Normal Inverse
>>> + * --------------------------------------------------
>>> + * Antenna switch to BT: | 0x280, 0x00
>>> + * Antenna switch to WiFi: | 0x0, 0x280
>>> + * Antenna switch to PTA: | 0x200, 0x80
>>> */
>>> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
>>> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>>
>> Per the documentation, shouldn't this be set to 0x200 then rather than 0x80?
>>
> Per the code before REG_S0S1_PATH_SWITCH setting, the driver has told
> the co-processor the antenna is inverse.
> memset(&h2c, 0, sizeof(struct h2c_cmd));
> h2c.ant_sel_rsv.cmd = H2C_8723B_ANT_SEL_RSV;
> h2c.ant_sel_rsv.ant_inverse = 1;
> h2c.ant_sel_rsv.int_switch_type = 0;
> rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
>
> At least the current modification is consistent with the antenna
> inverse setting.
> I'll verify on vendor driver about when/how the inverse be determined.
Fair enough :)
Cheers,
Jes
^ permalink raw reply
* [PATCH v4] ath9k: add loader for AR92XX (and older) pci(e)
From: Christian Lamparter @ 2019-07-05 17:53 UTC (permalink / raw)
To: QCA ath9k Development, linux-wireless
Cc: Kalle Valo, Julian Calaby, Martin Blumenstingl
Atheros cards with a AR92XX generation (and older) chip usually
store their pci(e) initialization vectors on an external eeprom chip.
However these chips technically don't need the eeprom chip attached,
the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
"... if the EEPROM content is not valid, a value of 0xFF1C returns
when read from the register". So, they will show up on the system's
pci bus. However in that state, ath9k can't load, since it relies
on having the correct pci-id, otherwise it doesn't know what chip it
actually is. This happens on many embedded devices like routers
and accesspoint since they want to keep the BOM low and store the
pci(e) initialization vectors together with the calibration data
on the system's FLASH, which is out of reach of the ath9k chip.
Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
Teleworker Gateway) need to be able to initialize the PCIe wifi device.
Normally, this should be done as a pci quirk during the early stages of
booting linux. However, this isn't possible for devices which have the
init code for the Atheros chip stored on NAND in an UBI volume.
Hence, this module can be used to initialize the chip when the
user-space is ready to extract the init code.
Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
v4: copy SPDX license identifier from "ath: fix SPDX tags" (ISC)
<https://www.spinics.net/lists/linux-wireless/msg187511.html>
and use the MODULE_LICENSE from ath9k (Dual BSD/GPL) to match
the ath9k module behavior 1:1.
v3: changed module description
v2: address Julian Calaby's comments:
- make it a separate driver again (much like OpenWrt)
- remove ar71xx leftovers (pdata)
---
drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
drivers/net/wireless/ath/ath9k/Makefile | 2 +
.../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
3 files changed, 233 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 5601cfd6a293..2d1247f61297 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,22 @@ config ATH9K_PCOEM
depends on ATH9K
default y
+config ATH9K_PCI_NO_EEPROM
+ tristate "Atheros ath9k pci loader for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ This separate driver provides a loader in order to support the
+ AR500X to AR92XX-generation of ath9k PCI(e) WiFi chips, which have
+ their initialization data (which contains the real PCI Device ID
+ that ath9k will need) stored together with the calibration data out
+ of reach for the ath9k chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index 15af0a836925..eff94bcd1f0a 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -77,3 +77,5 @@ ath9k_htc-y += htc_hst.o \
ath9k_htc-$(CONFIG_ATH9K_HTC_DEBUGFS) += htc_drv_debug.o
obj-$(CONFIG_ATH9K_HTC) += ath9k_htc.o
+
+obj-$(CONFIG_ATH9K_PCI_NO_EEPROM) += ath9k_pci_owl_loader.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
new file mode 100644
index 000000000000..159490f5a111
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: ISC
+/* Initialize Owl Emulation Devices
+ *
+ * Copyright (C) 2016 Christian Lamparter <chunkeey@gmail.com>
+ * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ *
+ * Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
+ * need to be able to initialize the PCIe wifi device. Normally, this is done
+ * during the early stages as a pci quirk.
+ * However, this isn't possible for devices which have the init code for the
+ * Atheros chip stored on UBI Volume on NAND. Hence, this module can be used to
+ * initialize the chip when the user-space is ready to extract the init code.
+ */
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/completion.h>
+#include <linux/etherdevice.h>
+#include <linux/firmware.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/ath9k_platform.h>
+
+struct owl_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+
+#define AR5416_EEPROM_MAGIC 0xa55a
+
+static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != AR5416_EEPROM_MAGIC) {
+ if (*cal_data != swab16(AR5416_EEPROM_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void owl_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct owl_ctx *ctx = (struct owl_ctx *)pci_get_drvdata(pdev);
+ struct pci_bus *bus;
+
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > 4096 || fw->size < 0x200 || (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (ath9k_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *owl_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ char *eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in ath9k/init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int owl_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct owl_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ if (pcim_enable_device(pdev))
+ return -EIO;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = owl_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev, owl_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ return err;
+}
+
+static void owl_remove(struct pci_dev *pdev)
+{
+ struct owl_ctx *ctx = pci_get_drvdata(pdev);
+
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+}
+
+static const struct pci_device_id owl_pci_table[] = {
+ { PCI_VDEVICE(ATHEROS, 0xff1c) }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d) }, /* PCI */
+ { },
+};
+MODULE_DEVICE_TABLE(pci, owl_pci_table);
+
+static struct pci_driver owl_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = owl_pci_table,
+ .probe = owl_probe,
+ .remove = owl_remove,
+};
+module_pci_driver(owl_driver);
+MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
+MODULE_DESCRIPTION("External EEPROM data loader for Atheros AR500X to AR92XX");
+MODULE_LICENSE("Dual BSD/GPL");
--
2.20.1
^ permalink raw reply related
* Re: [PATCH -next] carl9170: remove set but not used variable 'udev'
From: Christian Lamparter @ 2019-07-05 17:39 UTC (permalink / raw)
To: YueHaibing; +Cc: chunkeey, linux-kernel, netdev, linux-wireless, kvalo, davem
In-Reply-To: <20190702141207.47552-1-yuehaibing@huawei.com>
On Tuesday, July 2, 2019 4:12:07 PM CEST YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/carl9170/usb.c: In function carl9170_usb_disconnect:
> drivers/net/wireless/ath/carl9170/usb.c:1110:21:
> warning: variable udev set but not used [-Wunused-but-set-variable]
>
> It is not use since commit feb09b293327 ("carl9170:
> fix misuse of device driver API")
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
^ permalink raw reply
* [PATCH v2] libertas: Fix a double free in if_spi_c2h_data()
From: Dan Williams @ 2019-07-05 16:42 UTC (permalink / raw)
To: Kalle Valo
Cc: Philip Rakity, libertas-dev, kernel-janitors, linux-wireless,
Lubomir Rintel, Allison Randal, Dan Carpenter
In-Reply-To: <e679c9f99d6952f82924c71f036e4a196d0e72d4.camel@redhat.com>
The lbs_process_rxed_packet() frees the skb. It didn't originally, but
we fixed it in commit f54930f36311 ("libertas: don't leak skb on receive
error").
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
drivers/net/wireless/marvell/libertas/if_spi.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_spi.c b/drivers/net/wireless/marvell/libertas/if_spi.c
index 27067e79e83fe..072da89c4986f 100644
--- a/drivers/net/wireless/marvell/libertas/if_spi.c
+++ b/drivers/net/wireless/marvell/libertas/if_spi.c
@@ -766,19 +766,15 @@ static int if_spi_c2h_data(struct if_spi_card *card)
/* Read the data from the WLAN module into our skb... */
err = spu_read(card, IF_SPI_DATA_RDWRPORT_REG, data, ALIGN(len, 4));
- if (err)
- goto free_skb;
+ if (err) {
+ dev_kfree_skb(skb);
+ goto out
+ }
/* pass the SKB to libertas */
err = lbs_process_rxed_packet(card->priv, skb);
- if (err)
- goto free_skb;
+ /* lbs_process_rxed_packet() consumes the skb */
- /* success */
- goto out;
-
-free_skb:
- dev_kfree_skb(skb);
out:
if (err)
netdev_err(priv->dev, "%s: err=%d\n", __func__, err);
--
2.20.1
^ permalink raw reply related
* [PATCH] wl3501_cs: remove redundant variable ret
From: Colin King @ 2019-07-05 10:37 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable ret is being initialized with a value that is never
read and it is being updated later with a new value that is returned.
The variable is redundant and can be replaced with a return 0 as
there are no other return points in this function.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/wl3501_cs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index a25b17932edb..007bf6803293 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -1226,7 +1226,6 @@ static int wl3501_init_firmware(struct wl3501_card *this)
static int wl3501_close(struct net_device *dev)
{
struct wl3501_card *this = netdev_priv(dev);
- int rc = -ENODEV;
unsigned long flags;
struct pcmcia_device *link;
link = this->p_dev;
@@ -1241,10 +1240,9 @@ static int wl3501_close(struct net_device *dev)
/* Mask interrupts from the SUTRO */
wl3501_block_interrupt(this);
- rc = 0;
printk(KERN_INFO "%s: WL3501 closed\n", dev->name);
spin_unlock_irqrestore(&this->lock, flags);
- return rc;
+ return 0;
}
/**
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm
From: Luca Coelho @ 2019-07-05 8:51 UTC (permalink / raw)
To: Alexander Wetzel, johannes; +Cc: linux-wireless
In-Reply-To: <20190629195015.19680-4-alexander@wetzel-home.de>
On Sat, 2019-06-29 at 21:50 +0200, Alexander Wetzel wrote:
> All iwlwifi cards are able to handle multiple keyids per STA and are
> therefore fully compatible with the Extended Key ID implementation
> provided by mac80211.
>
> Allow Extended Key ID to be used for all mvm and dvm cards.
>
> Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
> ---
>
> This is basically the v2 patch of https://patchwork.kernel.org/patch/10931879/
> which Luca still has in his review queue. It just uses the new proposed
> simplified Extended Key ID API from this patch series instead.
>
> Merging (parts) of this series will of course break the older patch
> still queued to Luca, so this may need some coordination.
Thanks for your patch! I've dropped the old version and will wait until
Johannes merges the mac80211 part (and it reaches wireless-drivers-
next), so I can apply this.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 4/5] iwlwifi: mvm: remove unused .remove_sta_debugfs callback
From: Luciano Coelho @ 2019-07-05 8:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, Johannes Berg
Cc: Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo,
David S. Miller, Sara Sharon, Erel Geron, Avraham Stern,
linux-wireless, netdev
In-Reply-To: <20190612142658.12792-4-gregkh@linuxfoundation.org>
On Wed, 2019-06-12 at 16:26 +0200, Greg Kroah-Hartman wrote:
> The .remove_sta_debugfs callback was not doing anything in this driver,
> so remove it as it is not needed.
>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Cc: Intel Linux Wireless <linuxwifi@intel.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Sara Sharon <sara.sharon@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Erel Geron <erelx.geron@intel.com>
> Cc: Avraham Stern <avraham.stern@intel.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
Thanks, Greg! I applied this to our internal tree and it will reach the
mainline following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 3/5] iwlwifi: dvm: no need to check return value of debugfs_create functions
From: Luciano Coelho @ 2019-07-05 8:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Johannes Berg
Cc: Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo,
David S. Miller, linux-wireless, netdev
In-Reply-To: <20190612142658.12792-3-gregkh@linuxfoundation.org>
On Wed, 2019-06-12 at 16:26 +0200, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. This driver was saving the debugfs file away to be
> removed at a later time. However, the 80211 core would delete the whole
> directory that the debugfs files are created in, after it asks the
> driver to do the deletion, so just rely on the 80211 core to do all of
> the cleanup for us, making us not need to keep a pointer to the dentries
> around at all.
>
> This cleans up the structure of the driver data a bit and makes the code
> a tiny bit smaller.
>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Cc: Intel Linux Wireless <linuxwifi@intel.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
Thanks, Greg! I applied this to our internal tree and it will reach the
mainline following our normal upstreaming process.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] libertas: remove redundant assignment to variable ret
From: Colin King @ 2019-07-05 8:17 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, libertas-dev, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable ret is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/marvell/libertas/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/main.c b/drivers/net/wireless/marvell/libertas/main.c
index 5968852b65a7..2233b59cdf44 100644
--- a/drivers/net/wireless/marvell/libertas/main.c
+++ b/drivers/net/wireless/marvell/libertas/main.c
@@ -1046,7 +1046,7 @@ int lbs_rtap_supported(struct lbs_private *priv)
int lbs_start_card(struct lbs_private *priv)
{
struct net_device *dev = priv->dev;
- int ret = -1;
+ int ret;
/* poke the firmware */
ret = lbs_setup_firmware(priv);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-05 4:37 UTC (permalink / raw)
To: Daniel Drake
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAD8Lp45rYuE5WHx4vSbUhF10hOHam1aBLd52_aDKP8z2eeL4vA@mail.gmail.com>
On Fri, Jul 5, 2019 at 11:41 AM Daniel Drake <drake@endlessm.com> wrote:
>
> On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu <chiu@endlessm.com> wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> > we realized that the 8723bu's enable_rf() does the same thing as
> > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> > sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> > the cause of the wifi weak tx power. The vendor driver will set
> > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> > mechanism, by the function halbtc8723b1ant_PsTdma.
>
> Checking these details in the vendor driver:
> EXhalbtc8723b1ant_PowerOnSetting sets:
> pBoardInfo->btdmAntPos = BTC_ANTENNA_AT_AUX_PORT;
>
> Following the code flow from rtw_btcoex_HAL_Initialize(), this has a
> bWifiOnly parameter which will ultimately influence the final register
> value.
> Continuing the flow, we reach halbtc8723b1ant_SetAntPath() with
> bInitHwCfg=TRUE, bWifiOff=FALSE. antPosType is set to WIFI in the
> bWifiOnly case, and BT otherwise.
>
> I'm assuming that bUseExtSwitch = FALSE (existing rtl8xxxu code also
> seems to make the same assumption).
> For the bWifiOnly=FALSE case, it uses BT,
> pBtCoexist->fBtcWrite4Byte(pBtCoexist, 0x948, 0x0);
> and rtl8xxxu seems to do the same - seemingly routing the antenna path
> for BT only.
>
> As for halbtc8723b1ant_PsTdma() then being called in a way that causes
> it to switch to the PTA path a little later, it's more difficult to
> point out how that happens in an email, but I thin kwe can trust you
> on that :) There are certainly many callsites that would pass those
> parameters.
>
> > + * Different settings per different antenna position.
> > + * Antenna Position: | Normal Inverse
> > + * --------------------------------------------------
> > + * Antenna switch to BT: | 0x280, 0x00
> > + * Antenna switch to WiFi: | 0x0, 0x280
> > + * Antenna switch to PTA: | 0x200, 0x80
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> I don't really understand what we mean by an "inverse" antenna and my
> reading of the vendor driver leads me to another interpretation.
>
> The logic is based around an antenna position - btdmAntPos. It takes
> one of two values:
> BTC_ANTENNA_AT_MAIN_PORT = 0x1,
> BTC_ANTENNA_AT_AUX_PORT = 0x2,
>
> So the chip has pins to support two antennas - a "main" antenna and an
> "aux" one.
>
> We know we're dealing with a single antenna, so the actual module is
> going to only be using one of those antenna interfaces. If the chip
> tries to use the other antenna interface, it's effectively not using
> the antenna. So it's rather important to tell the chip to use the
> right interface.
>
> And that's exactly what happens here. btdmAntPos is hardcoded that the
> antenna is on the aux port for these devices, and this code is telling
> the chip that this is how things are wired up.
>
> The alternative way of calling this an antenna inverse (which the
> vendor driver also does in another section), i.e. "antenna is not
> connected to the main port but instead it's connected to the other
> one", seems less clear to me.
>
I agree with this part. From my past experience working on drivers for
WiFi access point, there's always a board config to describe how the
antenna wired up. The driver or firmware will select antennas from
something like txchainmask/rxchainmask to perform some smart
antenna and MIMO features. So The antenna position setting is quite
important for each wifi(MIMO) product because it could have impact on
the coverage and throughput. Back to the 1x1 rtl8723bu here, I think
it's the same thing. The antenna position is fixed in the factory and wired
to the AUX port. Maybe we can just take this antenna settings as the
default for 8723bu based on the assumption that there will be no other
antenna configuration.
Chris
> Even if we don't fully understand what's going on here, I'm convinced
> that your code change is fixing an inconsistency with the vendor
> driver, and most significantly, making the signal level actually
> usable on our devices. But if you agree with my interpretation of
> these values then maybe you could update the comment here!
>
> Daniel
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-05 3:44 UTC (permalink / raw)
To: Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <89dbfb9d-a31a-9ecb-66bd-42ac0fc49e70@gmail.com>
On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
> My point is this seems to be very dongle dependent :( We have to be
> careful not breaking it for some users while fixing it for others.
Do you still have your device?
Once we get to the point when you are happy with Chris's two patches
here on a code review level, we'll reach out to other driver
contributors plus people who previously complained about these types
of problems, and see if we can get some wider testing.
Larry, do you have these devices, can you help with testing too?
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-05 3:41 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <20190704105528.74028-1-chiu@endlessm.com>
On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu <chiu@endlessm.com> wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> we realized that the 8723bu's enable_rf() does the same thing as
> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> the cause of the wifi weak tx power. The vendor driver will set
> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> mechanism, by the function halbtc8723b1ant_PsTdma.
Checking these details in the vendor driver:
EXhalbtc8723b1ant_PowerOnSetting sets:
pBoardInfo->btdmAntPos = BTC_ANTENNA_AT_AUX_PORT;
Following the code flow from rtw_btcoex_HAL_Initialize(), this has a
bWifiOnly parameter which will ultimately influence the final register
value.
Continuing the flow, we reach halbtc8723b1ant_SetAntPath() with
bInitHwCfg=TRUE, bWifiOff=FALSE. antPosType is set to WIFI in the
bWifiOnly case, and BT otherwise.
I'm assuming that bUseExtSwitch = FALSE (existing rtl8xxxu code also
seems to make the same assumption).
For the bWifiOnly=FALSE case, it uses BT,
pBtCoexist->fBtcWrite4Byte(pBtCoexist, 0x948, 0x0);
and rtl8xxxu seems to do the same - seemingly routing the antenna path
for BT only.
As for halbtc8723b1ant_PsTdma() then being called in a way that causes
it to switch to the PTA path a little later, it's more difficult to
point out how that happens in an email, but I thin kwe can trust you
on that :) There are certainly many callsites that would pass those
parameters.
> + * Different settings per different antenna position.
> + * Antenna Position: | Normal Inverse
> + * --------------------------------------------------
> + * Antenna switch to BT: | 0x280, 0x00
> + * Antenna switch to WiFi: | 0x0, 0x280
> + * Antenna switch to PTA: | 0x200, 0x80
> */
> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
I don't really understand what we mean by an "inverse" antenna and my
reading of the vendor driver leads me to another interpretation.
The logic is based around an antenna position - btdmAntPos. It takes
one of two values:
BTC_ANTENNA_AT_MAIN_PORT = 0x1,
BTC_ANTENNA_AT_AUX_PORT = 0x2,
So the chip has pins to support two antennas - a "main" antenna and an
"aux" one.
We know we're dealing with a single antenna, so the actual module is
going to only be using one of those antenna interfaces. If the chip
tries to use the other antenna interface, it's effectively not using
the antenna. So it's rather important to tell the chip to use the
right interface.
And that's exactly what happens here. btdmAntPos is hardcoded that the
antenna is on the aux port for these devices, and this code is telling
the chip that this is how things are wired up.
The alternative way of calling this an antenna inverse (which the
vendor driver also does in another section), i.e. "antenna is not
connected to the main port but instead it's connected to the other
one", seems less clear to me.
Even if we don't fully understand what's going on here, I'm convinced
that your code change is fixing an inconsistency with the vendor
driver, and most significantly, making the signal level actually
usable on our devices. But if you agree with my interpretation of
these values then maybe you could update the comment here!
Daniel
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-05 2:27 UTC (permalink / raw)
To: Jes Sorensen
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <8f1454ca-4610-03d0-82c4-06174083d463@gmail.com>
On Fri, Jul 5, 2019 at 12:43 AM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>
> On 7/4/19 6:55 AM, Chris Chiu wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> > we realized that the 8723bu's enable_rf() does the same thing as
> > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> > sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> > the cause of the wifi weak tx power. The vendor driver will set
> > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> > mechanism, by the function halbtc8723b1ant_PsTdma.
> >
> > This commit hand over the antenna control to PTA(Packet Traffic
> > Arbitration), which compares the weight of bluetooth/wifi traffic
> > then determine whether to continue current wifi traffic or not.
> > After PTA take control, The wifi signal will be back to normal and
> > the bluetooth scan can also work at the same time. However, the
> > btcoexist still needs to be handled under different circumstances.
> > If there's a BT connection established, the wifi still fails to
> > connect until BT disconnected.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
> > ---
> >
> >
> > Note:
> > v2:
> > - Replace BIT(11) with the descriptive definition
> > - Meaningful comment for the REG_S0S1_PATH_SWITCH setting
> >
> >
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 11 ++++++++---
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> > 2 files changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > index 3adb1d3d47ac..ceffe05bd65b 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > /*
> > * WLAN action by PTA
> > */
> > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
> >
> > /*
> > * BT select S0/S1 controlled by WiFi
> > @@ -1568,9 +1568,14 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
> >
> > /*
> > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > + * Different settings per different antenna position.
> > + * Antenna Position: | Normal Inverse
> > + * --------------------------------------------------
> > + * Antenna switch to BT: | 0x280, 0x00
> > + * Antenna switch to WiFi: | 0x0, 0x280
> > + * Antenna switch to PTA: | 0x200, 0x80
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> Per the documentation, shouldn't this be set to 0x200 then rather than 0x80?
>
Per the code before REG_S0S1_PATH_SWITCH setting, the driver has told
the co-processor the antenna is inverse.
memset(&h2c, 0, sizeof(struct h2c_cmd));
h2c.ant_sel_rsv.cmd = H2C_8723B_ANT_SEL_RSV;
h2c.ant_sel_rsv.ant_inverse = 1;
h2c.ant_sel_rsv.int_switch_type = 0;
rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
At least the current modification is consistent with the antenna
inverse setting.
I'll verify on vendor driver about when/how the inverse be determined.
Chris
> We may need to put in place so
>
> Cheers,
> Jesme code to detect whether we have normal
> or inverse configuration of the dongle otherwise?
>
> I really appreciate you're digging into this!
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] nl80211: Fix undefined behavior in bit shift
From: Johannes Berg @ 2019-07-04 20:20 UTC (permalink / raw)
To: Jiunn Chang
Cc: Shuah Khan, linux-kernel-mentees, linux-wireless, linux-kernel
In-Reply-To: <20190704183432.av37fjd5s3zcho6m@rYz3n>
On Thu, 2019-07-04 at 13:34 -0500, Jiunn Chang wrote:
> Would you like me to send v3 with the change log in the patch description?
>
No no, like I said, it's not very useful in this case anyway.
johannes
^ permalink raw reply
* Re: [Linux-kernel-mentees][PATCH v2] nl80211: Fix undefined behavior in bit shift
From: Jiunn Chang @ 2019-07-04 18:34 UTC (permalink / raw)
To: Johannes Berg
Cc: Shuah Khan, linux-kernel-mentees, linux-wireless, linux-kernel
In-Reply-To: <8b8c44c3ecb8626d9bb5a8f786b1d2b7488df86b.camel@sipsolutions.net>
On Fri, Jun 28, 2019 at 03:57:05PM +0200, Johannes Berg wrote:
> On Wed, 2019-06-26 at 21:34 -0600, Shuah Khan wrote:
> > On 6/26/19 9:25 PM, Jiunn Chang wrote:
> > > Shifting signed 32-bit value by 31 bits is undefined. Changing most
> > > significant bit to unsigned.
> > >
> > > Changes included in v2:
> > > - use subsystem specific subject lines
> > > - CC required mailing lists
> > >
> > > Signed-off-by: Jiunn Chang <c0d1n61at3@gmail.com>
> > > ---
> >
> > Move version change lines here. They don't belong in the commit log.
>
> FWIW, in many cases people (maintainers) now *do* want them in the
> commit log. Here, they're just editorial, so agree, but if real
> technical changes were made due to reviews, they can indeed be useful.
>
> johannes
>
Hello Johannes,
Would you like me to send v3 with the change log in the patch description?
THX,
Jiunn
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Jes Sorensen @ 2019-07-04 16:43 UTC (permalink / raw)
To: Chris Chiu, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, linux
In-Reply-To: <20190704105528.74028-1-chiu@endlessm.com>
On 7/4/19 6:55 AM, Chris Chiu wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> we realized that the 8723bu's enable_rf() does the same thing as
> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> the cause of the wifi weak tx power. The vendor driver will set
> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> mechanism, by the function halbtc8723b1ant_PsTdma.
>
> This commit hand over the antenna control to PTA(Packet Traffic
> Arbitration), which compares the weight of bluetooth/wifi traffic
> then determine whether to continue current wifi traffic or not.
> After PTA take control, The wifi signal will be back to normal and
> the bluetooth scan can also work at the same time. However, the
> btcoexist still needs to be handled under different circumstances.
> If there's a BT connection established, the wifi still fails to
> connect until BT disconnected.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
> ---
>
>
> Note:
> v2:
> - Replace BIT(11) with the descriptive definition
> - Meaningful comment for the REG_S0S1_PATH_SWITCH setting
>
>
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 11 ++++++++---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> index 3adb1d3d47ac..ceffe05bd65b 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> /*
> * WLAN action by PTA
> */
> - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
>
> /*
> * BT select S0/S1 controlled by WiFi
> @@ -1568,9 +1568,14 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
>
> /*
> - * 0x280, 0x00, 0x200, 0x80 - not clear
> + * Different settings per different antenna position.
> + * Antenna Position: | Normal Inverse
> + * --------------------------------------------------
> + * Antenna switch to BT: | 0x280, 0x00
> + * Antenna switch to WiFi: | 0x0, 0x280
> + * Antenna switch to PTA: | 0x200, 0x80
> */
> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
Per the documentation, shouldn't this be set to 0x200 then rather than 0x80?
We may need to put in place some code to detect whether we have normal
or inverse configuration of the dongle otherwise?
I really appreciate you're digging into this!
Cheers,
Jes
^ permalink raw reply
* [PATCH 2/4] mt76: mt7615: move mt7615_mcu_set_rates to mac.c
From: Felix Fietkau @ 2019-07-04 15:53 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190704155324.56693-1-nbd@nbd.name>
It bypasses the MCU, so it does not belong in mcu.c
Also make mt7615_mac_tx_rate_val static
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
.../net/wireless/mediatek/mt76/mt7615/mac.c | 100 +++++++++++++++++-
.../net/wireless/mediatek/mt76/mt7615/main.c | 2 +-
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 88 ---------------
.../wireless/mediatek/mt76/mt7615/mt7615.h | 5 +-
4 files changed, 97 insertions(+), 98 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index 08cc3f46b011..49c14eb008d7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -248,9 +248,10 @@ void mt7615_tx_complete_skb(struct mt76_dev *mdev, enum mt76_txq_id qid,
mt76_tx_complete_skb(mdev, e->skb);
}
-u16 mt7615_mac_tx_rate_val(struct mt7615_dev *dev,
- const struct ieee80211_tx_rate *rate,
- bool stbc, u8 *bw)
+static u16
+mt7615_mac_tx_rate_val(struct mt7615_dev *dev,
+ const struct ieee80211_tx_rate *rate,
+ bool stbc, u8 *bw)
{
u8 phy, nss, rate_idx;
u16 rateval;
@@ -446,6 +447,95 @@ void mt7615_txp_skb_unmap(struct mt76_dev *dev,
le16_to_cpu(txp->len[i]), DMA_TO_DEVICE);
}
+void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
+ struct ieee80211_tx_rate *probe_rate,
+ struct ieee80211_tx_rate *rates)
+{
+ int wcid = sta->wcid.idx;
+ u32 addr = MT_WTBL_BASE + wcid * MT_WTBL_ENTRY_SIZE;
+ bool stbc = false;
+ int n_rates = sta->n_rates;
+ u8 bw, bw_prev, bw_idx = 0;
+ u16 val[4];
+ u16 probe_val;
+ u32 w5, w27;
+ int i;
+
+ if (!mt76_poll(dev, MT_WTBL_UPDATE, MT_WTBL_UPDATE_BUSY, 0, 5000))
+ return;
+
+ for (i = n_rates; i < 4; i++)
+ rates[i] = rates[n_rates - 1];
+
+ val[0] = mt7615_mac_tx_rate_val(dev, &rates[0], stbc, &bw);
+ bw_prev = bw;
+
+ if (probe_rate) {
+ probe_val = mt7615_mac_tx_rate_val(dev, probe_rate, stbc, &bw);
+ if (bw)
+ bw_idx = 1;
+ else
+ bw_prev = 0;
+ } else {
+ probe_val = val[0];
+ }
+
+ val[1] = mt7615_mac_tx_rate_val(dev, &rates[1], stbc, &bw);
+ if (bw_prev) {
+ bw_idx = 3;
+ bw_prev = bw;
+ }
+
+ val[2] = mt7615_mac_tx_rate_val(dev, &rates[2], stbc, &bw);
+ if (bw_prev) {
+ bw_idx = 5;
+ bw_prev = bw;
+ }
+
+ val[3] = mt7615_mac_tx_rate_val(dev, &rates[3], stbc, &bw);
+ if (bw_prev)
+ bw_idx = 7;
+
+ w27 = mt76_rr(dev, addr + 27 * 4);
+ w27 &= ~MT_WTBL_W27_CC_BW_SEL;
+ w27 |= FIELD_PREP(MT_WTBL_W27_CC_BW_SEL, bw);
+
+ w5 = mt76_rr(dev, addr + 5 * 4);
+ w5 &= ~(MT_WTBL_W5_BW_CAP | MT_WTBL_W5_CHANGE_BW_RATE);
+ w5 |= FIELD_PREP(MT_WTBL_W5_BW_CAP, bw) |
+ FIELD_PREP(MT_WTBL_W5_CHANGE_BW_RATE, bw_idx ? bw_idx - 1 : 7);
+
+ mt76_wr(dev, MT_WTBL_RIUCR0, w5);
+
+ mt76_wr(dev, MT_WTBL_RIUCR1,
+ FIELD_PREP(MT_WTBL_RIUCR1_RATE0, probe_val) |
+ FIELD_PREP(MT_WTBL_RIUCR1_RATE1, val[0]) |
+ FIELD_PREP(MT_WTBL_RIUCR1_RATE2_LO, val[0]));
+
+ mt76_wr(dev, MT_WTBL_RIUCR2,
+ FIELD_PREP(MT_WTBL_RIUCR2_RATE2_HI, val[0] >> 8) |
+ FIELD_PREP(MT_WTBL_RIUCR2_RATE3, val[1]) |
+ FIELD_PREP(MT_WTBL_RIUCR2_RATE4, val[1]) |
+ FIELD_PREP(MT_WTBL_RIUCR2_RATE5_LO, val[2]));
+
+ mt76_wr(dev, MT_WTBL_RIUCR3,
+ FIELD_PREP(MT_WTBL_RIUCR3_RATE5_HI, val[2] >> 4) |
+ FIELD_PREP(MT_WTBL_RIUCR3_RATE6, val[2]) |
+ FIELD_PREP(MT_WTBL_RIUCR3_RATE7, val[3]));
+
+ mt76_wr(dev, MT_WTBL_UPDATE,
+ FIELD_PREP(MT_WTBL_UPDATE_WLAN_IDX, wcid) |
+ MT_WTBL_UPDATE_RATE_UPDATE |
+ MT_WTBL_UPDATE_TX_COUNT_CLEAR);
+
+ mt76_wr(dev, addr + 27 * 4, w27);
+
+ if (!(sta->wcid.tx_info & MT_WCID_TX_INFO_SET))
+ mt76_poll(dev, MT_WTBL_UPDATE, MT_WTBL_UPDATE_BUSY, 0, 5000);
+
+ sta->rate_count = 2 * MT7615_RATE_RETRY * n_rates;
+ sta->wcid.tx_info |= MT_WCID_TX_INFO_SET;
+}
int mt7615_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
enum mt76_txq_id qid, struct mt76_wcid *wcid,
struct ieee80211_sta *sta,
@@ -470,7 +560,7 @@ int mt7615_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE) {
spin_lock_bh(&dev->mt76.lock);
msta->rate_probe = true;
- mt7615_mcu_set_rates(dev, msta, &info->control.rates[0],
+ mt7615_mac_set_rates(dev, msta, &info->control.rates[0],
msta->rates);
spin_unlock_bh(&dev->mt76.lock);
}
@@ -645,7 +735,7 @@ static bool mt7615_mac_add_txs_skb(struct mt7615_dev *dev,
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE) {
spin_lock_bh(&dev->mt76.lock);
if (sta->rate_probe) {
- mt7615_mcu_set_rates(dev, sta, NULL,
+ mt7615_mac_set_rates(dev, sta, NULL,
sta->rates);
sta->rate_probe = false;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 8fefcfba83b1..3f5f355d1f9b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -391,7 +391,7 @@ static void mt7615_sta_rate_tbl_update(struct ieee80211_hw *hw,
break;
}
msta->n_rates = i;
- mt7615_mcu_set_rates(dev, msta, NULL, msta->rates);
+ mt7615_mac_set_rates(dev, msta, NULL, msta->rates);
msta->rate_probe = false;
spin_unlock_bh(&dev->mt76.lock);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 0c9d1df86212..e57b51290c61 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -1647,92 +1647,4 @@ int mt7615_mcu_set_rx_ba(struct mt7615_dev *dev,
&wtbl_req, sizeof(wtbl_req), true);
}
-void mt7615_mcu_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
- struct ieee80211_tx_rate *probe_rate,
- struct ieee80211_tx_rate *rates)
-{
- int wcid = sta->wcid.idx;
- u32 addr = MT_WTBL_BASE + wcid * MT_WTBL_ENTRY_SIZE;
- bool stbc = false;
- int n_rates = sta->n_rates;
- u8 bw, bw_prev, bw_idx = 0;
- u16 val[4];
- u16 probe_val;
- u32 w5, w27;
- int i;
-
- if (!mt76_poll(dev, MT_WTBL_UPDATE, MT_WTBL_UPDATE_BUSY, 0, 5000))
- return;
-
- for (i = n_rates; i < 4; i++)
- rates[i] = rates[n_rates - 1];
-
- val[0] = mt7615_mac_tx_rate_val(dev, &rates[0], stbc, &bw);
- bw_prev = bw;
-
- if (probe_rate) {
- probe_val = mt7615_mac_tx_rate_val(dev, probe_rate, stbc, &bw);
- if (bw)
- bw_idx = 1;
- else
- bw_prev = 0;
- } else {
- probe_val = val[0];
- }
-
- val[1] = mt7615_mac_tx_rate_val(dev, &rates[1], stbc, &bw);
- if (bw_prev) {
- bw_idx = 3;
- bw_prev = bw;
- }
-
- val[2] = mt7615_mac_tx_rate_val(dev, &rates[2], stbc, &bw);
- if (bw_prev) {
- bw_idx = 5;
- bw_prev = bw;
- }
-
- val[3] = mt7615_mac_tx_rate_val(dev, &rates[3], stbc, &bw);
- if (bw_prev)
- bw_idx = 7;
-
- w27 = mt76_rr(dev, addr + 27 * 4);
- w27 &= ~MT_WTBL_W27_CC_BW_SEL;
- w27 |= FIELD_PREP(MT_WTBL_W27_CC_BW_SEL, bw);
-
- w5 = mt76_rr(dev, addr + 5 * 4);
- w5 &= ~(MT_WTBL_W5_BW_CAP | MT_WTBL_W5_CHANGE_BW_RATE);
- w5 |= FIELD_PREP(MT_WTBL_W5_BW_CAP, bw) |
- FIELD_PREP(MT_WTBL_W5_CHANGE_BW_RATE, bw_idx ? bw_idx - 1 : 7);
-
- mt76_wr(dev, MT_WTBL_RIUCR0, w5);
-
- mt76_wr(dev, MT_WTBL_RIUCR1,
- FIELD_PREP(MT_WTBL_RIUCR1_RATE0, probe_val) |
- FIELD_PREP(MT_WTBL_RIUCR1_RATE1, val[0]) |
- FIELD_PREP(MT_WTBL_RIUCR1_RATE2_LO, val[0]));
- mt76_wr(dev, MT_WTBL_RIUCR2,
- FIELD_PREP(MT_WTBL_RIUCR2_RATE2_HI, val[0] >> 8) |
- FIELD_PREP(MT_WTBL_RIUCR2_RATE3, val[1]) |
- FIELD_PREP(MT_WTBL_RIUCR2_RATE4, val[1]) |
- FIELD_PREP(MT_WTBL_RIUCR2_RATE5_LO, val[2]));
-
- mt76_wr(dev, MT_WTBL_RIUCR3,
- FIELD_PREP(MT_WTBL_RIUCR3_RATE5_HI, val[2] >> 4) |
- FIELD_PREP(MT_WTBL_RIUCR3_RATE6, val[2]) |
- FIELD_PREP(MT_WTBL_RIUCR3_RATE7, val[3]));
-
- mt76_wr(dev, MT_WTBL_UPDATE,
- FIELD_PREP(MT_WTBL_UPDATE_WLAN_IDX, wcid) |
- MT_WTBL_UPDATE_RATE_UPDATE |
- MT_WTBL_UPDATE_TX_COUNT_CLEAR);
-
- mt76_wr(dev, addr + 27 * 4, w27);
-
- if (!(sta->wcid.tx_info & MT_WCID_TX_INFO_SET))
- mt76_poll(dev, MT_WTBL_UPDATE, MT_WTBL_UPDATE_BUSY, 0, 5000);
-
- sta->rate_count = 2 * MT7615_RATE_RETRY * n_rates;
- sta->wcid.tx_info |= MT_WCID_TX_INFO_SET;
-}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index 3713db874ef4..1135023507b1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -151,7 +151,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev, struct ieee80211_vif *vif,
int mt7615_mcu_set_wtbl_key(struct mt7615_dev *dev, int wcid,
struct ieee80211_key_conf *key,
enum set_key_cmd cmd);
-void mt7615_mcu_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
+void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
struct ieee80211_tx_rate *probe_rate,
struct ieee80211_tx_rate *rates);
int mt7615_mcu_wtbl_bmc(struct mt7615_dev *dev, struct ieee80211_vif *vif,
@@ -206,9 +206,6 @@ static inline void mt7615_irq_disable(struct mt7615_dev *dev, u32 mask)
mt76_set_irq_mask(&dev->mt76, MT_INT_MASK_CSR, mask, 0);
}
-u16 mt7615_mac_tx_rate_val(struct mt7615_dev *dev,
- const struct ieee80211_tx_rate *rate,
- bool stbc, u8 *bw);
int mt7615_mac_write_txwi(struct mt7615_dev *dev, __le32 *txwi,
struct sk_buff *skb, struct mt76_wcid *wcid,
struct ieee80211_sta *sta, int pid,
--
2.17.0
^ permalink raw reply related
* [PATCH 4/4] mt76: mt7615: sync with mt7603 rate control changes
From: Felix Fietkau @ 2019-07-04 15:53 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190704155324.56693-1-nbd@nbd.name>
- 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
- Switch from lower rates to higher rates more conservatively
- enable hardware rate up/down selection
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
.../net/wireless/mediatek/mt76/mt7615/init.c | 19 ++-
.../net/wireless/mediatek/mt76/mt7615/mac.c | 129 +++++++++++++-----
.../wireless/mediatek/mt76/mt7615/mt7615.h | 11 +-
.../net/wireless/mediatek/mt76/mt7615/regs.h | 9 ++
4 files changed, 124 insertions(+), 44 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index a6c2a132f960..280db9445d94 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -45,11 +45,19 @@ static void mt7615_mac_init(struct mt7615_dev *dev)
mt76_wr(dev, MT_DMA_DCR0, MT_DMA_DCR0_RX_VEC_DROP |
FIELD_PREP(MT_DMA_DCR0_MAX_RX_LEN, 3072));
- mt76_wr(dev, MT_AGG_ARUCR, FIELD_PREP(MT_AGG_ARxCR_LIMIT(0), 7));
+ mt76_wr(dev, MT_AGG_ARUCR,
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(0), 7) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(1), 2) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(2), 2) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(3), 2) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(4), 1) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(5), 1) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(6), 1) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(7), 1));
+
mt76_wr(dev, MT_AGG_ARDCR,
- FIELD_PREP(MT_AGG_ARxCR_LIMIT(0), 0) |
- FIELD_PREP(MT_AGG_ARxCR_LIMIT(1),
- max_t(int, 0, MT7615_RATE_RETRY - 2)) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(0), MT7615_RATE_RETRY - 1) |
+ FIELD_PREP(MT_AGG_ARxCR_LIMIT(1), MT7615_RATE_RETRY - 1) |
FIELD_PREP(MT_AGG_ARxCR_LIMIT(2), MT7615_RATE_RETRY - 1) |
FIELD_PREP(MT_AGG_ARxCR_LIMIT(3), MT7615_RATE_RETRY - 1) |
FIELD_PREP(MT_AGG_ARxCR_LIMIT(4), MT7615_RATE_RETRY - 1) |
@@ -58,8 +66,7 @@ static void mt7615_mac_init(struct mt7615_dev *dev)
FIELD_PREP(MT_AGG_ARxCR_LIMIT(7), MT7615_RATE_RETRY - 1));
mt76_wr(dev, MT_AGG_ARCR,
- (MT_AGG_ARCR_INIT_RATE1 |
- FIELD_PREP(MT_AGG_ARCR_RTS_RATE_THR, 2) |
+ (FIELD_PREP(MT_AGG_ARCR_RTS_RATE_THR, 2) |
MT_AGG_ARCR_RATE_DOWN_RATIO_EN |
FIELD_PREP(MT_AGG_ARCR_RATE_DOWN_RATIO, 1) |
FIELD_PREP(MT_AGG_ARCR_RATE_UP_EXTRA_TH, 4)));
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index b896d8ce9e72..5bfb4594b8ee 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -451,6 +451,7 @@ void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
struct ieee80211_tx_rate *probe_rate,
struct ieee80211_tx_rate *rates)
{
+ struct ieee80211_tx_rate *ref;
int wcid = sta->wcid.idx;
u32 addr = MT_WTBL_BASE + wcid * MT_WTBL_ENTRY_SIZE;
bool stbc = false;
@@ -459,7 +460,8 @@ void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
u16 val[4];
u16 probe_val;
u32 w5, w27;
- int i;
+ bool rateset;
+ int i, k;
if (!mt76_poll(dev, MT_WTBL_UPDATE, MT_WTBL_UPDATE_BUSY, 0, 5000))
return;
@@ -467,6 +469,43 @@ void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
for (i = n_rates; i < 4; i++)
rates[i] = rates[n_rates - 1];
+ rateset = !(sta->rate_set_tsf & BIT(0));
+ memcpy(sta->rateset[rateset].rates, rates,
+ sizeof(sta->rateset[rateset].rates));
+ if (probe_rate) {
+ sta->rateset[rateset].probe_rate = *probe_rate;
+ ref = &sta->rateset[rateset].probe_rate;
+ } else {
+ sta->rateset[rateset].probe_rate.idx = -1;
+ ref = &sta->rateset[rateset].rates[0];
+ }
+
+ rates = sta->rateset[rateset].rates;
+ for (i = 0; i < ARRAY_SIZE(sta->rateset[rateset].rates); i++) {
+ /*
+ * We don't support switching between short and long GI
+ * within the rate set. For accurate tx status reporting, we
+ * need to make sure that flags match.
+ * For improved performance, avoid duplicate entries by
+ * decrementing the MCS index if necessary
+ */
+ if ((ref->flags ^ rates[i].flags) & IEEE80211_TX_RC_SHORT_GI)
+ rates[i].flags ^= IEEE80211_TX_RC_SHORT_GI;
+
+ for (k = 0; k < i; k++) {
+ if (rates[i].idx != rates[k].idx)
+ continue;
+ if ((rates[i].flags ^ rates[k].flags) &
+ (IEEE80211_TX_RC_40_MHZ_WIDTH |
+ IEEE80211_TX_RC_80_MHZ_WIDTH |
+ IEEE80211_TX_RC_160_MHZ_WIDTH))
+ continue;
+
+ rates[i].idx--;
+ }
+
+ }
+
val[0] = mt7615_mac_tx_rate_val(dev, &rates[0], stbc, &bw);
bw_prev = bw;
@@ -513,17 +552,17 @@ void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
mt76_wr(dev, MT_WTBL_RIUCR1,
FIELD_PREP(MT_WTBL_RIUCR1_RATE0, probe_val) |
FIELD_PREP(MT_WTBL_RIUCR1_RATE1, val[0]) |
- FIELD_PREP(MT_WTBL_RIUCR1_RATE2_LO, val[0]));
+ FIELD_PREP(MT_WTBL_RIUCR1_RATE2_LO, val[1]));
mt76_wr(dev, MT_WTBL_RIUCR2,
- FIELD_PREP(MT_WTBL_RIUCR2_RATE2_HI, val[0] >> 8) |
+ FIELD_PREP(MT_WTBL_RIUCR2_RATE2_HI, val[1] >> 8) |
FIELD_PREP(MT_WTBL_RIUCR2_RATE3, val[1]) |
- FIELD_PREP(MT_WTBL_RIUCR2_RATE4, val[1]) |
+ FIELD_PREP(MT_WTBL_RIUCR2_RATE4, val[2]) |
FIELD_PREP(MT_WTBL_RIUCR2_RATE5_LO, val[2]));
mt76_wr(dev, MT_WTBL_RIUCR3,
FIELD_PREP(MT_WTBL_RIUCR3_RATE5_HI, val[2] >> 4) |
- FIELD_PREP(MT_WTBL_RIUCR3_RATE6, val[2]) |
+ FIELD_PREP(MT_WTBL_RIUCR3_RATE6, val[3]) |
FIELD_PREP(MT_WTBL_RIUCR3_RATE7, val[3]));
mt76_wr(dev, MT_WTBL_UPDATE,
@@ -533,6 +572,9 @@ void mt7615_mac_set_rates(struct mt7615_dev *dev, struct mt7615_sta *sta,
mt76_wr(dev, addr + 27 * 4, w27);
+ mt76_set(dev, MT_LPON_T0CR, MT_LPON_T0CR_MODE); /* TSF read */
+ sta->rate_set_tsf = (mt76_rr(dev, MT_LPON_UTTR0) & ~BIT(0)) | rateset;
+
if (!(sta->wcid.tx_info & MT_WCID_TX_INFO_SET))
mt76_poll(dev, MT_WTBL_UPDATE, MT_WTBL_UPDATE_BUSY, 0, 5000);
@@ -562,9 +604,9 @@ int mt7615_tx_prepare_skb(struct mt76_dev *mdev, void *txwi_ptr,
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE) {
spin_lock_bh(&dev->mt76.lock);
- msta->rate_probe = true;
mt7615_mac_set_rates(dev, msta, &info->control.rates[0],
msta->rates);
+ msta->rate_probe = true;
spin_unlock_bh(&dev->mt76.lock);
}
@@ -616,9 +658,13 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
struct ieee80211_tx_info *info, __le32 *txs_data)
{
struct ieee80211_supported_band *sband;
- int i, idx, count, final_idx = 0;
+ struct mt7615_rate_set *rs;
+ int first_idx = 0, last_idx;
+ int i, idx, count;
bool fixed_rate, ack_timeout;
bool probe, ampdu, cck = false;
+ bool rs_idx;
+ u32 rate_set_tsf;
u32 final_rate, final_rate_flags, final_nss, txs;
fixed_rate = info->status.rates[0].count;
@@ -629,6 +675,7 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
txs = le32_to_cpu(txs_data[3]);
count = FIELD_GET(MT_TXS3_TX_COUNT, txs);
+ last_idx = FIELD_GET(MT_TXS3_LAST_TX_RATE, txs);
txs = le32_to_cpu(txs_data[0]);
final_rate = FIELD_GET(MT_TXS0_TX_RATE, txs);
@@ -650,38 +697,56 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
if (ampdu || (info->flags & IEEE80211_TX_CTL_AMPDU))
info->flags |= IEEE80211_TX_STAT_AMPDU | IEEE80211_TX_CTL_AMPDU;
+ first_idx = max_t(int, 0, last_idx - (count + 1) / MT7615_RATE_RETRY);
+
if (fixed_rate && !probe) {
info->status.rates[0].count = count;
+ i = 0;
goto out;
}
- for (i = 0, idx = 0; i < ARRAY_SIZE(info->status.rates); i++) {
- int cur_count = min_t(int, count, 2 * MT7615_RATE_RETRY);
+ rate_set_tsf = READ_ONCE(sta->rate_set_tsf);
+ rs_idx = !((u32)(FIELD_GET(MT_TXS4_F0_TIMESTAMP, le32_to_cpu(txs_data[4])) -
+ rate_set_tsf) < 1000000);
+ rs_idx ^= rate_set_tsf & BIT(0);
+ rs = &sta->rateset[rs_idx];
- if (!i && probe) {
- cur_count = 1;
- } else {
- info->status.rates[i] = sta->rates[idx];
- idx++;
- }
+ if (!first_idx && rs->probe_rate.idx >= 0) {
+ info->status.rates[0] = rs->probe_rate;
- if (i && info->status.rates[i].idx < 0) {
- info->status.rates[i - 1].count += count;
- break;
+ spin_lock_bh(&dev->mt76.lock);
+ if (sta->rate_probe) {
+ mt7615_mac_set_rates(dev, sta, NULL, sta->rates);
+ sta->rate_probe = false;
}
+ spin_unlock_bh(&dev->mt76.lock);
+ } else
+ info->status.rates[0] = rs->rates[first_idx / 2];
+ info->status.rates[0].count = 0;
- if (!count) {
- info->status.rates[i].idx = -1;
- break;
- }
+ for (i = 0, idx = first_idx; count && idx <= last_idx; idx++) {
+ struct ieee80211_tx_rate *cur_rate;
+ int cur_count;
- info->status.rates[i].count = cur_count;
- final_idx = i;
+ cur_rate = &rs->rates[idx / 2];
+ cur_count = min_t(int, MT7615_RATE_RETRY, count);
count -= cur_count;
+
+ if (idx && (cur_rate->idx != info->status.rates[i].idx ||
+ cur_rate->flags != info->status.rates[i].flags)) {
+ i++;
+ if (i == ARRAY_SIZE(info->status.rates))
+ break;
+
+ info->status.rates[i] = *cur_rate;
+ info->status.rates[i].count = 0;
+ }
+
+ info->status.rates[i].count += cur_count;
}
out:
- final_rate_flags = info->status.rates[final_idx].flags;
+ final_rate_flags = info->status.rates[i].flags;
switch (FIELD_GET(MT_TX_RATE_MODE, final_rate)) {
case MT_PHY_TYPE_CCK:
@@ -713,8 +778,8 @@ static bool mt7615_fill_txs(struct mt7615_dev *dev, struct mt7615_sta *sta,
return false;
}
- info->status.rates[final_idx].idx = final_rate;
- info->status.rates[final_idx].flags = final_rate_flags;
+ info->status.rates[i].idx = final_rate;
+ info->status.rates[i].flags = final_rate_flags;
return true;
}
@@ -735,16 +800,6 @@ static bool mt7615_mac_add_txs_skb(struct mt7615_dev *dev,
if (skb) {
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
- if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE) {
- spin_lock_bh(&dev->mt76.lock);
- if (sta->rate_probe) {
- mt7615_mac_set_rates(dev, sta, NULL,
- sta->rates);
- sta->rate_probe = false;
- }
- spin_unlock_bh(&dev->mt76.lock);
- }
-
if (!mt7615_fill_txs(dev, sta, info, txs_data)) {
ieee80211_tx_info_clear_status(info);
info->status.rates[0].idx = -1;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index 1135023507b1..2f43101343c3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -42,12 +42,21 @@ enum mt7615_hw_txq_id {
MT7615_TXQ_FWDL,
};
+struct mt7615_rate_set {
+ struct ieee80211_tx_rate probe_rate;
+ struct ieee80211_tx_rate rates[4];
+};
+
struct mt7615_sta {
struct mt76_wcid wcid; /* must be first */
struct mt7615_vif *vif;
- struct ieee80211_tx_rate rates[8];
+ struct ieee80211_tx_rate rates[4];
+
+ struct mt7615_rate_set rateset[2];
+ u32 rate_set_tsf;
+
u8 rate_count;
u8 n_rates;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/regs.h b/drivers/net/wireless/mediatek/mt76/mt7615/regs.h
index ea40581dc870..f2cd858730c3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/regs.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/regs.h
@@ -187,6 +187,15 @@
#define MT_WTBL_W27_CC_BW_SEL GENMASK(6, 5)
+#define MT_LPON_BASE 0x24200
+#define MT_LPON(_n) (MT_LPON_BASE + (_n))
+
+#define MT_LPON_T0CR MT_LPON(0x010)
+#define MT_LPON_T0CR_MODE GENMASK(1, 0)
+
+#define MT_LPON_UTTR0 MT_LPON(0x018)
+#define MT_LPON_UTTR1 MT_LPON(0x01c)
+
#define MT_EFUSE_BASE 0x81070000
#define MT_EFUSE_BASE_CTRL 0x000
#define MT_EFUSE_BASE_CTRL_EMPTY BIT(30)
--
2.17.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox