The hardware needs a byte-count table with the size of each frame
on the queue to build A-MPDUs, but:
* newer generation no longer have the duplicated space at the end,
they can deal with the wrap properly - and we don't even fill
the dup anyway
* we have a maximum queue size of 512 right now and don't use the
theoretical hardware maximum of 65536.
Together, this reduces the byte count table DMA allocation from
64KiB (65536*2 + 64*2 rounded up) to 1 KiB (though that might be
rounded up to a full 4 KiB page by the allocator, not sure it can
share the allocations.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200425130140.c263b787b5ab.I059507a9760b1ce1d45d84dcaa91629a5cfb58e0@changeid
First set of patches for v5.8. Changes all over, ath10k apparently
seeing most new features this time. rtw88 also had lots of changes due
to preparation for new hardware support.
In this pull request there's also a new macro to include/linux/iopoll:
read_poll_timeout_atomic(). This is needed by rtw88 for atomic
polling.
Major changes:
ath11k
* add debugfs file for testing ADDBA and DELBA
* add 802.11 encapsulation offload on hardware support
* add htt_peer_stats_reset debugfs file
ath10k
* enable VHT160 and VHT80+80 modes
* enable radar detection in secondary segment
* sdio: disable TX complete indication to improve throughput
* sdio: decrease power consumption
* sdio: add HTT TX bundle support to increase throughput
* sdio: add rx bitrate reporting
ath9k
* improvements to AR9002 calibration logic
carl9170
* remove buggy P2P_GO support
p54usb
* add support for AirVasT USB stick
rtw88
* add support for antenna configuration
ti wlcore
* add support for AES_CMAC cipher
iwlwifi
* support for a few new FW API versions
* new hw configs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJetAhAAAoJEG4XJFUm622bADEH/A1OjAD3H1iZyTmXHP4T7yZe
TKJ+9I6B3BDR1czUTm+kUhrgBDNpdLLtu+b+5QXfpPLrtZ0FF/zjuazgueyqQpZ1
zudj+rG72njHpU0RKtO7wIBrCtckLPV0be+3026hztatJmJ7XQ9FvsanFPPsrrNv
0lh8E8kDUSynOW2me8FW1GBgDkGaBaicAs4FSjwNJC31Wo/VN5m9gEFkGpT1VJWP
l0xeEQ/N2mknQVuTR4CuMT9VJ0SNlJrLZpBVAqkmc170c3pKChl3LTNCnP925ye9
Nfqw2sQKgUPJKRbZR5wZTphGuu4krFv0ldWCvb0oFtZlCLIkiOz6+AA7b33oV2A=
=7ewK
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-2020-05-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.8
First set of patches for v5.8. Changes all over, ath10k apparently
seeing most new features this time. rtw88 also had lots of changes due
to preparation for new hardware support.
In this pull request there's also a new macro to include/linux/iopoll:
read_poll_timeout_atomic(). This is needed by rtw88 for atomic
polling.
Major changes:
ath11k
* add debugfs file for testing ADDBA and DELBA
* add 802.11 encapsulation offload on hardware support
* add htt_peer_stats_reset debugfs file
ath10k
* enable VHT160 and VHT80+80 modes
* enable radar detection in secondary segment
* sdio: disable TX complete indication to improve throughput
* sdio: decrease power consumption
* sdio: add HTT TX bundle support to increase throughput
* sdio: add rx bitrate reporting
ath9k
* improvements to AR9002 calibration logic
carl9170
* remove buggy P2P_GO support
p54usb
* add support for AirVasT USB stick
rtw88
* add support for antenna configuration
ti wlcore
* add support for AES_CMAC cipher
iwlwifi
* support for a few new FW API versions
* new hw configs
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
On newer hardware, the tx_queue debugfs file would need to
allocate 37.5kib data since there are 512 queues, which is
too much. Rather than resorting to kludges like kvmalloc(),
use the seq_file API to print out the data.
While at it, also fix a NULL pointer dereference here, the
txq pointer from trans_pcie->txqs[] may be NULL if that
queue hasn't been allocated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200417131727.491cf8224c49.I7f154d81e5becef3b5ff22d7c6e36170bde0d7d5@changeid
In the context info, we need to indicate the correct RB size
to the device so that it will not think we have 4k when we
only use 2k. This seems to not have caused any issues right
now, likely because the hardware no longer supports putting
multiple entries into a single RB, and practically all of
the entries should be smaller than 2k.
Nevertheless, it's a bug, and we must advertise the right
size to the device.
Note that right now we can only tell it 2k vs. 4k, so for
the cases where we have more, still use 4k. This needs to
be fixed by the firmware first.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: cfdc20efeb ("iwlwifi: pcie: use partial pages if applicable")
Cc: stable@vger.kernel.org # v5.6
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20200417100405.ae6cd345764f.I0985c55223decf70182b9ef1d8edf4179f537853@changeid
The iwl_trans_pcie_dyn_txq_free() function only releases the frames
that may be left on the queue by calling iwl_pcie_gen2_txq_unmap(),
but doesn't actually free the DMA ring or byte-count tables for the
queue. This leads to pretty large memory leaks (at least before my
queue size improvements), in particular in monitor/sniffer mode on
channel hopping since this happens on every channel change.
This was also now more evident after the move to a DMA pool for the
byte count tables, showing messages such as
BUG iwlwifi:bc (...): Objects remaining in iwlwifi:bc on __kmem_cache_shutdown()
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=206811.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: 6b35ff9157 ("iwlwifi: pcie: introduce a000 TX queues management")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20200417100405.f5f4c4193ec1.Id5feebc9b4318041913a9c89fc1378bb5454292c@changeid
There's no need for this to be exposed outside of the tx.c
file, make it static.
Change-Id: I41d40008311b108d0578bd2ec73c5477e700a839
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We don't support the FPGA versions of this card combination anymore.
Remove the cfg mangling that tries to load it and all the relevant
structures.
Change-Id: I190652101afcab682cfba873d062992f11efca32
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
A couple of SoCs, which can be recognized by PCI device IDs 0xA0F0 and
0x43F0, need a longer wait for the xtal to stabilize. To handle this,
add a new trans_cfg structure for Qu devices with a larger
xtal_latency value and apply them to the devices recognized by these
IDs. Also add a flag that allows us to inform the FW that the low
latency xtal should be used.
Change-Id: I8a14c6af45ea14d8e7f1ef38a589158f38d0c0ea
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Now that we identify the correct cfgs with the new tables for Qu step
C and QuZ with Jf, we can remove the mangling we do later on.
Change-Id: Ic01ce67db147e897ad2424f0e05a70a00d2c620e
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
All the QnJ devices have a similar matching to the other Qu devices,
but needs a different configuration. Convert the QnJ devices to the
new table accordingly.
Change-Id: If236ef3d0da3e605a3379922818f5897e0affd7e
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add new generic iwl_trans structures for these devices and apply the
correct cfg depending on the device characteristics.
Since we have to match Qu with IWL_CONFIG_ANY, we also need to move
the Hr devices to the new table, but for now we keep matching on PCI
device and subsystem device IDs.
Change-Id: I14e9146a99621ff11ce50bc746a4b88af508fee0
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We need to use different firmware versions for different HW steps with
certain devices. Prepare for this differentiation by adding HW step
to the new device table.
Change-Id: Ib1afb7b0c89e9dc2d26e6d32ea19e978c17ba1dd
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
These values are selected based on the PCI device ID, so the decision
to use them can be made early. By moving them to the trans_cfg, we
avoid duplicating the large cfg structs for small pieces of
data (sometimes a single boolean). This will also allow us to make
more decisions based on, for instance, the SoC type in used.
The trans_cfg concept changes a bit, because previously it was used
only to boot the device before reading further characteristics and now
it also contains more data that is associated with the device ID.
Change-Id: Ib71b07ea9e322eb74571dc5e8aa58f17eece5c9c
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The iwl9560_2ac_cfg struct is used for PNJ devices and the
configuration is the same as iwl9260_2ac_cfg, so we can remove the
former to avoid redundancy.
Change-Id: I17ac1802f00bd80006930b922a9fc21df60e3c16
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add the read_config32 op to allow dumping the config space when
needed.
Change-Id: Ib2d254a38a4bfb95dcc3d04eec91781827a0c623
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
TH1 devices can now be fully differentiated by using the device
parameters we have (particularly the RF_TYPE). Start using these
parameters instead of hardcoding to specific subsystem device IDs.
This also fixes the name of one of the TH1 devices that was
erroneously using the 9260 struct and renames 9160 to 9162.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.18d4304b5454.Ib168d186da88393e9ec46f0fca523edb48d9138e@changeid
Devices that also include a GNSS module have different names, so add a
new device option to differentiate them, according to the values we
have in the modules section of the subsystem device ID.
Additionally, convert the two applicable devices to use this value
instead of hardcoded subsystem IDs.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.1f958e558d05.I45492bb57cbbeb4cc0ec84313bade4def7377a27@changeid
Second set of patches for v5.6. Nothing special standing out, smaller
new features and fixes allover.
Major changes:
ar5523
* add support for SMCWUSBT-G2 USB device
iwlwifi
* support new versions of the FTM FW APIs
* support new version of the beacon template FW API
* print some extra information when the driver is loaded
rtw88
* support wowlan feature for 8822c
* add support for WIPHY_WOWLAN_NET_DETECT
brcmfmac
* add initial support for monitor mode
qtnfmac
* add module parameter to enable DFS offloading in firmware
* add support for STA HE rates
* add support for TWT responder and spatial reuse
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJeLcWsAAoJEG4XJFUm622bDGUIAJuhM4LiDAzOGnDjH5cMosOC
/qwDpGD19cEeVAhNSMKUn7Uo9+qbQYIleiO7XXxzCuJceYbxbT5s3Vb/fWsRUPjS
cBDmGuK8/giqMQJshXvfCTsoF83CyirCjY/MJvomK2BRlXM8hQ3s6hAcfU0zQ96e
OU1akcfZzUwjaBKaDYLncxLuGbeUXMy8AZwFdgQlQRMoObpen/IIwx6jDK/A+3l6
VCOJF+JTkDytfNWmTpZ65uJrYEXoLe6G4028FjOI4BDFmEgvdHC5vTm7VOBhrkuB
9tsKcYNvECCNn2WI96V+etD8kaZPscQIW8hgOrYyGxw43lJg5zH4Z9eWAmHojxE=
=UOhb
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-2020-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.6
Second set of patches for v5.6. Nothing special standing out, smaller
new features and fixes allover.
Major changes:
ar5523
* add support for SMCWUSBT-G2 USB device
iwlwifi
* support new versions of the FTM FW APIs
* support new version of the beacon template FW API
* print some extra information when the driver is loaded
rtw88
* support wowlan feature for 8822c
* add support for WIPHY_WOWLAN_NET_DETECT
brcmfmac
* add initial support for monitor mode
qtnfmac
* add module parameter to enable DFS offloading in firmware
* add support for STA HE rates
* add support for TWT responder and spatial reuse
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
* Support new versions of the FTM FW APIs;
* Fix an old bug in D3 (WoWLAN);
* A couple of fixes/improvements in the receive-buffers code;
* Fix in the debugging where we were skipping one TXQ;
* Support new version of the beacon template FW API;
* Print some extra information when the driver is loaded;
* Some debugging infrastructure (aka. yoyo) updates;
* Support for a new HW version;
* Second phase of device configuration work started;
* Some clean-ups;
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEF3LNfgb2BPWm68smoUecoho8xfoFAl4ZmgQACgkQoUecoho8
xfqEmQ/9EuV/rOANfiPQUL1wKl3u2tT8DviH7DFcT7z18U6ghDxn3ElRKTt9bz3T
yfr1QYuttW9oQibgF75bosp7beNJRf6UUqfv175JxVhLqTHDmgiFzPD67SceBcBB
bT1n0isXzhzZx0tZQNNXPYgnTy42mTJKY86l6imPrji41WuHGCUNAZnJj57BCeDY
LSX4JDO6wz/KaNznwlMGkDn3TIZFeqNh9/j0vDXzHA/FPUvq8voU7/alcE2DgjqC
vSxunFclCSoKX7/qoqnQE5tzBTsGh8LJHI7sD3CAueuDP7vacMJCY//IVLNkmfyA
03zIt26OLT9irc98uEhwc2AuyDBmAYZd3O7kfEmeg7yp5ffLbyWX0uefhi4SQI81
/0SJeY7Ylf8NVarE2QJmmTOYft8W9v71IWCdgmx1mRotQtebhNzWLho2bXAdLwwj
OFPb9lXCdgPqCmBgE2I1PP0iWtEOvkAzb+mrmpclElShYf63Py3mf9Y5cjoqLi2e
QZtjLCMpGNh3aZPSjVDMgXMZv6WxLB/fFmX3O8NDgBExaKh0rvG7j7b8A4URonVq
I4ngnBUSXzZ48yiAmlKL++QanuHXsHkDuLOiErKXiC8wwWE+7EGopxZ4vq7oSkao
mBdoB4HcQYfO+sO+J8rWNZdp4EMeXyBDW3ce1d7lTqyEjPbMM+8=
=Ovcw
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-for-kalle-2020-01-11' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
First set of patches intended for v5.6
* Support new versions of the FTM FW APIs;
* Fix an old bug in D3 (WoWLAN);
* A couple of fixes/improvements in the receive-buffers code;
* Fix in the debugging where we were skipping one TXQ;
* Support new version of the beacon template FW API;
* Print some extra information when the driver is loaded;
* Some debugging infrastructure (aka. yoyo) updates;
* Support for a new HW version;
* Second phase of device configuration work started;
* Some clean-ups;
Second set of fixes for v5.5. There are quite a few patches,
especially on iwlwifi, due to me being on a long break. Libertas also
has a security fix and mt76 a build fix.
iwlwifi
* don't send the PPAG command when PPAG is disabled, since it can cause problems
* a few fixes for a HW bug
* a fix for RS offload;
* a fix for 3168 devices where the NVM tables where the wrong tables were being read
* fix a couple of potential memory leaks in TXQ code
* disable L0S states in all hardware since our hardware doesn't
officially support them anymore (and older versions of the hardware
had instability in these states)
* remove lar_disable parameter since it has been causing issues for
some people who erroneously disable it
* force the debug monitor HW to stop also when debug is disabled,
since it sometimes stays on and prevents low system power states
* don't send IWL_MVM_RXQ_NSSN_SYNC notification due to DMA problems
libertas
* fix two buffer overflows
mt76
* build fix related to CONFIG_MT76_LEDS
* fix off by one in bitrates handling
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJeKX2wAAoJEG4XJFUm622bG8QH/3+QXaSJAVqzbQh2boy7aS88
xhrrnh+bSqWY0ChMk0Z73RF8Ek0WlO+os4uN1cbWIWujrdQUPbTBtOwX4d0TzTue
E3tBFPiHTlVtU43z1bsprA+6EE7fqt/H2lWtlxk0IHzeiQY9NcB6BlDKKCzk5Hib
aMb5HCQy4JmSK83E60HLM9L4nEmEP+yveaKL7uaAZw+qkmyk2mT6um0TlmOYVoNG
9V6k3OZto8LvyV6jKPZgVI6QBATnwHDxlWgooYRj54PuCj9hTbR2mcuUL2QyQeze
AX2QNI+1kWIrAiDaU/lOj8579SiUl36iqtuKmtLhDnSe1GxDkrzmawtz3aGDm4k=
=VZox
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-2020-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for v5.5
Second set of fixes for v5.5. There are quite a few patches,
especially on iwlwifi, due to me being on a long break. Libertas also
has a security fix and mt76 a build fix.
iwlwifi
* don't send the PPAG command when PPAG is disabled, since it can cause problems
* a few fixes for a HW bug
* a fix for RS offload;
* a fix for 3168 devices where the NVM tables where the wrong tables were being read
* fix a couple of potential memory leaks in TXQ code
* disable L0S states in all hardware since our hardware doesn't
officially support them anymore (and older versions of the hardware
had instability in these states)
* remove lar_disable parameter since it has been causing issues for
some people who erroneously disable it
* force the debug monitor HW to stop also when debug is disabled,
since it sometimes stays on and prevents low system power states
* don't send IWL_MVM_RXQ_NSSN_SYNC notification due to DMA problems
libertas
* fix two buffer overflows
mt76
* build fix related to CONFIG_MT76_LEDS
* fix off by one in bitrates handling
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 323ebb61e3 ("net: use listified RX for handling GRO_NORMAL
skbs") introduces batching of GRO_NORMAL packets in napi_frags_finish,
and commit 6570bc79c0 ("net: core: use listified Rx for GRO_NORMAL in
napi_gro_receive()") adds the same to napi_skb_finish. However,
dev_gro_receive (that is called just before napi_{frags,skb}_finish) can
also pass skbs to the networking stack: e.g., when the GRO session is
flushed, napi_gro_complete is called, which passes pp directly to
netif_receive_skb_internal, skipping napi->rx_list. It means that the
packet stored in pp will be handled by the stack earlier than the
packets that arrived before, but are still waiting in napi->rx_list. It
leads to TCP reorderings that can be observed in the TCPOFOQueue counter
in netstat.
This commit fixes the reordering issue by making napi_gro_complete also
use napi->rx_list, so that all packets going through GRO will keep their
order. In order to keep napi_gro_flush working properly, gro_normal_list
calls are moved after the flush to clear napi->rx_list.
iwlwifi calls napi_gro_flush directly and does the same thing that is
done by gro_normal_list, so the same change is applied there:
napi_gro_flush is moved to be before the flush of napi->rx_list.
A few other drivers also use napi_gro_flush (brocade/bna/bnad.c,
cortina/gemini.c, hisilicon/hns3/hns3_enet.c). The first two also use
napi_complete_done afterwards, which performs the gro_normal_list flush,
so they are fine. The latter calls napi_gro_receive right after
napi_gro_flush, so it can end up with non-empty napi->rx_list anyway.
Fixes: 323ebb61e3 ("net: use listified RX for handling GRO_NORMAL skbs")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Cc: Alexander Lobakin <alobakin@dlink.ru>
Cc: Edward Cree <ecree@solarflare.com>
Acked-by: Alexander Lobakin <alobakin@dlink.ru>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Acked-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We have a lot of mostly duplicated data structures that are repeated
only because the device name string is different. To avoid this, move
the string from the cfg to the trans structure and add it
independently from the rest of the configuration to the PCI mapping
tables.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add a new device table that contains information that can be checked
at runtime in order to decide which configuration to use. This allows
us to map the full cfg independently from the tran-specific
configuration.
This is the first step in creating the new table. Subsequent patches
will add the possibility of checking different values at runtime in
order to make the decision.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
With the new concept of separating the trans-specific (trans_cfg) data
from the rest of the cfg, we will start mapping only the trans_cfg
part to the PCI device ID/subsystem device ID. So we can assume that
the data passed to the probe function contains the trans_cfg, but
since the full cfg still contains the trans_cfg at the beginning, we
can allow a full cfg to be passed as well. This makes it easier to
convert the existing tables one by one.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
L0S states have been found to be unstable with our devices and in
newer hardware they are not supported at all, so we must always set
the L0S_DISABLED bit. Previously we were only disabling L0S states if
L1 was supported, because the assumption was that transitions from L0S
to L1 state was the problematic case. But now we should never use
L0S, so do it regardless of whether L1 is supported or not.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This bit has been misnamed since the initial implementation of the
driver. The correct semantics is that setting this bit disables L0S
states, and we already clearly use it as such in the code. Rename it
to avoid confusion.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We needed this abstraction for some CSR registers for
IWL_DEVICE_22560, but that has been removed, so we don't need the
abstraction anymore. Remove it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
