When the error check in ath9k_hw_read_revisions() was added, it checked for
-EIO which is what ath9k_regread() in the ath9k_htc driver uses. However,
for plain ath9k, the register read function uses ioread32(), which just
returns -1 on error. So if such a read fails, it still gets passed through
and ends up as a weird mac revision in the log output.
Fix this by changing ath9k_regread() to return -1 on error like ioread32()
does, and fix the error check to look for that instead of -EIO.
Fixes: 2f90c7e5d0 ("ath9k: Check for errors when reading SREV register")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210326180819.142480-1-toke@redhat.com
Johannes Berg says:
====================
Another set of updates, all over the map:
* set sk_pacing_shift for 802.3->802.11 encap offload
* some monitor support for 802.11->802.3 decap offload
* HE (802.11ax) spec updates
* userspace API for TDLS HE support
* along with various other small features, cleanups and
fixups
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
of_get_mac_address() returns a "const void*" pointer to a MAC address.
Lately, support to fetch the MAC address by an NVMEM provider was added.
But this will only work with platform devices. It will not work with
PCI devices (e.g. of an integrated root complex) and esp. not with DSA
ports.
There is an of_* variant of the nvmem binding which works without
devices. The returned data of a nvmem_cell_read() has to be freed after
use. On the other hand the return of_get_mac_address() points to some
static data without a lifetime. The trick for now, was to allocate a
device resource managed buffer which is then returned. This will only
work if we have an actual device.
Change it, so that the caller of of_get_mac_address() has to supply a
buffer where the MAC address is written to. Unfortunately, this will
touch all drivers which use the of_get_mac_address().
Usually the code looks like:
const char *addr;
addr = of_get_mac_address(np);
if (!IS_ERR(addr))
ether_addr_copy(ndev->dev_addr, addr);
This can then be simply rewritten as:
of_get_mac_address(np, ndev->dev_addr);
Sometimes is_valid_ether_addr() is used to test the MAC address.
of_get_mac_address() already makes sure, it just returns a valid MAC
address. Thus we can just test its return code. But we have to be
careful if there are still other sources for the MAC address before the
of_get_mac_address(). In this case we have to keep the
is_valid_ether_addr() call.
The following coccinelle patch was used to convert common cases to the
new style. Afterwards, I've manually gone over the drivers and fixed the
return code variable: either used a new one or if one was already
available use that. Mansour Moufid, thanks for that coccinelle patch!
<spml>
@a@
identifier x;
expression y, z;
@@
- x = of_get_mac_address(y);
+ x = of_get_mac_address(y, z);
<...
- ether_addr_copy(z, x);
...>
@@
identifier a.x;
@@
- if (<+... x ...+>) {}
@@
identifier a.x;
@@
if (<+... x ...+>) {
...
}
- else {}
@@
identifier a.x;
expression e;
@@
- if (<+... x ...+>@e)
- {}
- else
+ if (!(e))
{...}
@@
expression x, y, z;
@@
- x = of_get_mac_address(y, z);
+ of_get_mac_address(y, z);
... when != x
</spml>
All drivers, except drivers/net/ethernet/aeroflex/greth.c, were
compile-time tested.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kalle Valo says:
====================
wireless-drivers-next patches for v5.13
First set of patches for v5.13. I have been offline for a couple of
and I have a smaller pull request this time. The next one will be
bigger. Nothing really special standing out.
ath11k
* add initial support for QCN9074, but not enabled yet due to firmware problems
* enable radar detection for 160MHz secondary segment
* handle beacon misses in station mode
rtw88
* 8822c: support firmware crash dump
mt7601u
* enable TDLS support
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
MODULE_SUPPORTED_DEVICE was added in pre-git era and never was
implemented. We can safely remove it, because the kernel has grown
to have many more reliable mechanisms to determine if device is
supported or not.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ath.git patches for v5.13. Major changes:
ath11k
* add initial support for QCN9074, but not enabled yet due to firmware problems
* enable radar detection for 160MHz secondary segment
* handle beacon misses in station mode
When AP goes down without any indication to STA, firmware detects
missing beacon, and sends wmi roam event with reason BEACON_MISS
to the host.
Added support for STA mode to trigger disassociation from AP,
on receiving this event from firmware.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01717-QCAHKSWPL_SILICONZ-1
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Lavanya Suresh <lavaks@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1614340859-28867-1-git-send-email-lavaks@codeaurora.org
Currently, though the peer rssi information is updated to station dump
from driver sta_statistics mac op, the info doesn't get updated
since the NL80211_STA_INFO_SIGNAL filled flag is not set in station
info. Hence update this flag while filling the rssi info.
Tested on: IPQ8074 WLAN.HK.2.1.0.1-01213-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sriram R <srirrama@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210224090241.3098-1-srirrama@codeaurora.org
Currently in the shutdown callback we wait for recovery to complete
before freeing up the resources. This results in additional two seconds
delay during the shutdown and thereby increase the shutdown time.
As an attempt to take less time during shutdown, remove the wait for
recovery completion in the shutdown callback and added an API to freeing
the reosurces in which they were common for shutdown and removing
the module.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
Signed-off-by: Youghandhar Chintala <youghand@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210223142908.23374-1-youghand@codeaurora.org
Commit c134d1f8c4 ("ath11k: Handle errors if peer creation fails") completely
broke AP mode on QCA6390:
kernel: [ 151.230734] ath11k_pci 0000:06:00.0: failed to create peer after vdev start delay: -22
wpa_supplicant[2307]: Failed to set beacon parameters
wpa_supplicant[2307]: Interface initialization failed
wpa_supplicant[2307]: wlan0: interface state UNINITIALIZED->DISABLED
wpa_supplicant[2307]: wlan0: AP-DISABLED
wpa_supplicant[2307]: wlan0: Unable to setup interface.
wpa_supplicant[2307]: Failed to initialize AP interface
This was because commit c134d1f8c4 ("ath11k: Handle errors if peer creation
fails") added error handling for ath11k_peer_create(), which had been failing
all along but was unnoticed due to the missing error handling. The actual bug
was introduced already in commit aa44b2f3ec ("ath11k: start vdev if a bss peer is
already created").
ath11k_peer_create() was failing because for AP mode the peer is created
already earlier op_add_interface() and we should skip creation here, but the
check for modes was wrong. Fixing that makes AP mode work again.
This shouldn't affect IPQ8074 nor QCN9074 as they have hw_params.vdev_start_delay disabled.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Fixes: c134d1f8c4 ("ath11k: Handle errors if peer creation fails")
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1614006849-25764-1-git-send-email-kvalo@codeaurora.org
If CONFIG_ARCH_DMA_ADDR_T_64BIT=n:
drivers/net/wireless/ath/ath11k/qmi.c: In function ‘ath11k_qmi_respond_fw_mem_request’:
drivers/net/wireless/ath/ath11k/qmi.c:1690:8: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 5 has type ‘dma_addr_t’ {aka ‘unsigned int’} [-Wformat=]
1690 | "qmi req mem_seg[%d] 0x%llx %u %u\n", i,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1691 | ab->qmi.target_mem[i].paddr,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| dma_addr_t {aka unsigned int}
drivers/net/wireless/ath/ath11k/debug.h:64:30: note: in definition of macro ‘ath11k_dbg’
64 | __ath11k_dbg(ar, dbg_mask, fmt, ##__VA_ARGS__); \
| ^~~
drivers/net/wireless/ath/ath11k/qmi.c:1690:34: note: format string is defined here
1690 | "qmi req mem_seg[%d] 0x%llx %u %u\n", i,
| ~~~^
| |
| long long unsigned int
| %x
Fixes: d5395a5486 ("ath11k: qmi: add debug message for allocated memory segment addresses and sizes")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210221182754.2071863-1-geert@linux-m68k.org
This reverts commit a56c14bb21.
ath_tx_process_buffer() doesn't dereference or check sta and passes it
to ath_tx_complete_aggr() and ath_tx_complete_buf().
ath_tx_complete_aggr() checks the pointer before use. No problem here.
ath_tx_complete_buf() doesn't check or dereference sta and passes it on
to ath_tx_complete(). ath_tx_complete() doesn't check or dereference sta,
but assigns it to tx_info->status.status_driver_data[0]
ath_tx_complete_buf() is called from ath_tx_complete_aggr() passing
null ieee80211_sta pointer.
There is a potential for dereference later on, if and when the
tx_info->status.status_driver_data[0]is referenced. In addition, the
rcu read lock might be released before referencing the contents.
ath_tx_complete_buf() should be fixed to check sta perhaps? Worth
looking into.
Reverting this patch because it doesn't solve the problem and introduces
memory leak by skipping buffer completion if the pointer (sta) is NULL.
Fixes: a56c14bb21 ("ath9k: fix ath_tx_process_buffer() potential null ptr dereference")
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210217211801.22540-1-skhan@linuxfoundation.org
When transmitting to a receiver in dynamic SMPS mode, all transmissions that
use multiple spatial streams need to be sent using CTS-to-self or RTS/CTS to
give the receiver's extra chains some time to wake up.
This fixes the tx rate getting stuck at <= MCS7 for some clients, especially
Intel ones, which make aggressive use of SMPS.
Cc: stable@vger.kernel.org
Reported-by: Martin Kennedy <hurricos@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210214184911.96702-1-nbd@nbd.name
QCN9074 is PCI based 11ax radio.
- has 2G/5G/6G variants.
- has NSS 2x2 and 4x4 variants.
QCN9074 uses 45MB of HOST DDR memory, target requests host memory in
segments, each segment is of 2MB size and is physcial contiguous and
use static window configuration.
Currently there are still two issues with QCN9074, see below. So we don't add
QCN9074 PCI id yet to make sure the driver is loaded. The id will be added only
after the issues are fixed.
Issue 1:
ath11k_pci 0000:06:00.0: qmi failed memory request, err = -110
ath11k_pci 0000:06:00.0: qmi failed to respond fw mem req:-110
Issue 2:
ath11k_pci 0000:06:00.0: firmware crashed: MHI_CB_SYS_ERROR
ath11k_pci 0000:06:00.0: qmi failed set mode request, mode: 0, err = -110
ath11k_pci 0000:06:00.0: qmi failed to send wlan fw mode:-110
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612946530-28504-12-git-send-email-akolli@codeaurora.org
Define host CE configuration for QCN9074 since the max CE count is six.
Available MSI interrupt is five so cannot able to map the ce_id directly
for the msi_data_idx. Added get_ce_msi_idx ops in ath11k_hif_ops to get
the CE MSI idx which is used to initialize the CE ring.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612946530-28504-10-git-send-email-akolli@codeaurora.org
hal rx descriptor is different for QCN9074 target type. since
rx_msdu_end, rx_msdu_start, rx_mpdu_start elements are in
different placement/alignment. In order to have generic data path,
introduce platform specific hal rx descriptor access ops in
ath11k_hw_ops.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612946530-28504-9-git-send-email-akolli@codeaurora.org
Three window slots can be configure. First window slot
dedicate for dynamic selection and remaining two slots
dedicate for static selection. To optimise the window
selection, frequent registers (UMAC, CE) are configure
in static window slot. so that we minimise the window
selection. Other registers are configure in dynamic window
slot. Get the window start address from the respective
offset and access the read/write register.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1.r2-00012-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <periyasa@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612946530-28504-7-git-send-email-akolli@codeaurora.org
Kalle Valo says:
====================
wireless-drivers-next patches for v5.12
Second set of patches for v5.12. Last time there was a smaller pull
request so unsurprisingly this time we have a big one. mt76 has new
hardware support and lots of new features, iwlwifi getting new
features and rtw88 got NAPI support. And the usual cleanups and fixes
all over.
Major changes:
ath10k
* support setting SAR limits via nl80211
rtw88
* support 8821 RFE type2 devices
* NAPI support
iwlwifi
* add new FW API support
* support for new So devices
* support for RF interference mitigation (RFI)
* support for PNVM (Platform Non-Volatile Memory, a firmware data
file) from BIOS
mt76
* add new mt7921e driver
* 802.11 encap offload support
* support for multiple pcie gen1 host interfaces on 7915
* 7915 testmode support
* 7915 txbf support
brcmfmac
* support for CQM RSSI notifications
wil6210
* support for extended DMG MCS 12.1 rate
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
I have received feedback that QCA6390 PCI support is working for many, and I'm
also using QCA6390 on my daily driver^Hlaptop. While there are issues still
to be resolved it's not really experimental anymore, so remove the experimental
warning from driver initialisation.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1613040697-20289-1-git-send-email-kvalo@codeaurora.org
ieee80211_report_used_skb of mac80211 use the frame_control of
ieee80211_hdr in sk_buff and indicate it to another function
ieee80211_mgd_conn_tx_status, then it queue work ieee80211_sta_work,
but ieee80211_is_auth(fc) in ieee80211_sta_work check fail when the
authentication has transmitted by ath10k.
When the ath10k report it with HTT_TX_COMPL_STATE_DISCARD, it will be
set without flag IEEE80211_TX_STAT_ACK, then mac80211 should try the
next authentication immeditely, but in fact mac80211 wait 1 second for
it, the reason is ieee80211_is_auth(fc) in ieee80211_sta_work check
fail for the sk_buff which is not restored, the data of sk_buff is not
the begin of ieee80211_hdr, in fact it is the begin of htt_cmd_hdr.
dmesg without this patch, it wait 1 second for the next retry when
ath10k report without IEEE80211_TX_STAT_ACK for authentication:
[ 6973.883116] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 1/3)
[ 6974.705471] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 2/3)
[ 6975.712962] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 3/3)
Restore the sk_buff make mac8011 retry the next authentication
immeditely which meet logic of mac80211.
dmesg with this patch, it retry the next immeditely when ath10k
report without IEEE80211_TX_STAT_ACK for authentication:
[ 216.734813] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 1/3)
[ 216.739914] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 2/3)
[ 216.745874] wlan0: send auth to 5e:6f:2b:0d:fb:d7 (try 3/3)
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612839530-2263-1-git-send-email-wgong@codeaurora.org
