IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Somehow we missed this for a long time, but similar to the extended
NSS support in VHT capabilities, we need to have this in Operating
Mode notification.
Implement it by
* parsing the 160/80+80 bit there and setting the bandwidth
appropriately
* having callers of ieee80211_get_vht_max_nss() pass in the current
max NSS value as received in the operating mode notification in
order to modify it appropriately depending on the extended NSS
bits.
This updates all drivers that use it, i.e. only iwlwifi/mvm.
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.20200326150855.098483728cfa.I4e8c25d3288441759c2793247197229f0696a37d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Due to some hardware issues, queue 31 isn't usable on devices that have
32 queues (7000, 8000, 9000 families), which is correctly reflected in
the configuration and TX queue initialization.
However, the firmware API and queue allocation code assumes that there
are 32 queues, and if something actually attempts to use #31 this leads
to a NULL-pointer dereference since it's not allocated.
Fix this by limiting to 31 in the IWL_MVM_DQA_MAX_DATA_QUEUE, and also
add some code to catch this earlier in the future, if the configuration
changes perhaps.
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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.98a79be2db6a.I3a4af6b03b87a6bc18db9b1ff9a812f397bee1fc@changeid
Kalle Valo says:
====================
wireless-drivers-next patches for v5.7
Third set of patches for v5.7. Nothing really special this time,
business as usual.
When pulling this to net-next there's again a conflict in:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:
IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),
And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.
Major changes:
brcmfmac
* add USB autosuspend support
ath11k
* handle RX fragments
* enable PN offload
* add support for HE BSS color
iwlwifi
* support new FW API version
* support for EDCA measurements
* new scan API features
* enable new firmware debugging code
====================
Kalle gave me directions on how to resolve the iwlwifi conflict
as follows:
====================
When pulling this to net-next there's again a conflict in:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:
IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),
And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Some of the places using this want the newline, but not all,
so remove the newline from it and generate it in the debugfs
files where it's desired.
The effect of this is not printing double newlines in debug
log messages.
Change-Id: Ia59b0abbef16b6783fcabc095c5fde16bd047a26
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The FW changed the maximum number of scan offload profiles to 8 in new
APIs. Support it by changing the scan_offload_profile_cfg struct to be
more dynamic, so we can reuse most of the code and only change size of
the profiles array.
Change-Id: I65210cf541af46e2675a8c764d5871f7f5b070d6
Signed-off-by: Tova Mussai <tova.mussai@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This new command is mostly backwards compatible, with the exception
that the device_type element was changed into a bitmask. The device
type bit remains the same (because we only had 0 and 1 anyway), but
when using v1 we can't set any other bits, because that would change
the integer.
Other than that, the struct remains the same and the driver can set
the device_type bit in both cases, but it can only set the low_latency
bit if VER_2 is used.
Change-Id: Ib68d4c821ebcce253b42ed0ea15881fb4e3e01da
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>
We shouldn't do this just for HT/VHT, but be future-proof
and also check for HE.
Change-Id: Icaeff714c00a773681dbfee72558afd1c7121c5d
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
That closing brace for the switch statement is misplaced, fix it.
Change-Id: I39af135a9e3fc64337d2cced43a70cb48fe3b9c1
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Modify adaptive dwell number of APs override API
Instead of using channel to index mapping, add the adaptive dwell
override parameters as part of the configuration per channel in the scan
request command.
Support 2 different override values and use them as follows:
1. 10 APs for friendly GO channels in p2p scan.
2. 2 APs for social channels in p2p scan.
Change-Id: I3b461108abf2306c3d054099112f2c3afce1cc92
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Some devices require longer time to stabilize the power and XTAL.
This is especially true for devices integrated in the SoC. Add
support for a new firmware API that allows the driver to set the
latency value accordingly.
Change-Id: I6829a46b89e4e701f80a0e4033f4dd41ee44ed12
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Overlapping header include additions in macsec.c
A bug fix in 'net' overlapping with the removal of 'version'
string in ena_netdev.c
Overlapping test additions in selftests Makefile
Overlapping PCI ID table adjustments in iwlwifi driver.
Signed-off-by: David S. Miller <davem@davemloft.net>
Johannes Berg says:
====================
A few big new things:
* 802.11 frame encapsulation offload support
* more HE (802.11ax) support, including some for 6 GHz band
* powersave in hwsim, for better testing
Of course as usual there are various cleanups and small fixes.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The logic for checking required NVM sections was recently fixed in
commit b3f20e0982 ("iwlwifi: mvm: fix NVM check for 3168
devices"). However, with that fixed the else is now taken for 3168
devices and within the else clause there is a mandatory check for the
PHY_SKU section. This causes the parsing to fail for 3168 devices.
The PHY_SKU section is really only mandatory for the IWL_NVM_EXT
layout (the phy_sku parameter of iwl_parse_nvm_data is only used when
the NVM type is IWL_NVM_EXT). So this changes the PHY_SKU section
check so that it's only mandatory for IWL_NVM_EXT.
Fixes: b3f20e0982 ("iwlwifi: mvm: fix NVM check for 3168 devices")
Signed-off-by: Dan Moulding <dmoulding@me.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Continue the wakeup flow only if no FW CPUs have an error
If we don't check for error in all FW CPUs the driver can think
based on one CPU that the FW is operational and try to access
and send commands.
Also, handle the error_id endianness correctly as le32
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
I changed the API for asking for a session protection but
I omitted the TDLS flows. Fix that now.
Note that for the TDLS flow, we need to block until the
session protection actually starts, so add this option
to iwl_mvm_schedule_session_protection.
This patch fixes a firmware assert in the TDLS flow since
the old TIME_EVENT_CMD is not supported anymore by newer
firwmare versions.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: fe959c7b20 ("iwlwifi: mvm: use the new session protection command")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fix a kernel panic by checking that the sta is not NULL.
This could happen during a reconfig flow, as mac80211 moves the sta
between all the states without really checking if the previous state was
successfully set. So, if for some reason we failed to add back the
station, subsequent calls to sta_state() callback will be done when the
station is NULL. This would result in a following panic:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000040
IP: iwl_mvm_cfg_he_sta+0xfc/0x690 [iwlmvm]
[..]
Call Trace:
iwl_mvm_mac_sta_state+0x629/0x6f0 [iwlmvm]
drv_sta_state+0xf4/0x950 [mac80211]
ieee80211_reconfig+0xa12/0x2180 [mac80211]
ieee80211_restart_work+0xbb/0xe0 [mac80211]
process_one_work+0x1e2/0x610
worker_thread+0x4d/0x3e0
[..]
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When a FTM request is aborted, the driver sends the abort command to
the fw and waits for a response. When the response arrives, the driver
calls cfg80211_pmsr_complete() for that request.
However, cfg80211 frees the requested data immediately after sending
the abort command, so this may lead to use after free.
Fix it by clearing the request data in the driver when the abort
command arrives and ignoring the fw notification that will come
afterwards.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Fixes: fc36ffda32 ("iwlwifi: mvm: support FTM initiator")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Till now, the driver asked the fw for a DTS measurement in automatic
mode. This triggered a flow in which the fw actively measured the
temperature. This is not needed anymore, as the fw performs
measurements by itself, without the driver triggering them, and the
current cadence in which the fw performs such measurements is
sufficient.
In addition, in some time-sensitive scenarios, in which the driver asks
the fw for an active measurement twice in a short time (<100ms), the fw
asserts with code 0x20100801.
Change the DTS measurement to _WITHOUT_MEASURE instead, so the fw will
respond with the last measurement it has performed.
Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The IGTK keys are only removed by mac80211 after it has already
removed the AP station. This causes the driver to throw an error
because mac80211 is trying to remove the IGTK when the station doesn't
exist anymore.
The firmware is aware that the station has been removed and can deal
with it the next time we try to add an IGTK for a station, so we
shouldn't try to remove the key if the station ID is
IWL_MVM_INVALID_STA. Do this by removing the check for mvm_sta before
calling iwl_mvm_send_sta_igtk() and check return from that function
gracefully if the station ID is invalid.
Cc: stable@vger.kernel.org # 4.12+
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Use a unique name when registering a thermal zone. Otherwise, with
multiple NICS, we hit the following warning during the unregistration.
WARNING: CPU: 2 PID: 3525 at fs/sysfs/group.c:255
RIP: 0010:sysfs_remove_group+0x80/0x90
Call Trace:
dpm_sysfs_remove+0x57/0x60
device_del+0x5a/0x350
? sscanf+0x4e/0x70
device_unregister+0x1a/0x60
hwmon_device_unregister+0x4a/0xa0
thermal_remove_hwmon_sysfs+0x175/0x1d0
thermal_zone_device_unregister+0x188/0x1e0
iwl_mvm_thermal_exit+0xe7/0x100 [iwlmvm]
iwl_op_mode_mvm_stop+0x27/0x180 [iwlmvm]
_iwl_op_mode_stop.isra.3+0x2b/0x50 [iwlwifi]
iwl_opmode_deregister+0x90/0xa0 [iwlwifi]
__exit_compat+0x10/0x2c7 [iwlmvm]
__x64_sys_delete_module+0x13f/0x270
do_syscall_64+0x5a/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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>
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;
The purpose of this was to keep all the queues updated with
the Rx sequence numbers because unlikely yet possible
situations where queues can't understand if a specific
packet needs to be dropped or not.
Unfortunately, it was reported that this caused issues in
our DMA engine. We don't fully understand how this is related,
but this is being currently debugged. For now, just don't send
this notification to the Rx queues. This de-facto reverts my
commit 3c514bf831:
iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues
This issue was reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=204873https://bugzilla.kernel.org/show_bug.cgi?id=205001
and others maybe.
Fixes: 3c514bf831 ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues")
CC: <stable@vger.kernel.org> # 5.3+
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
It is now possible to propagate BSS color settings into the subsystem. Lets
make mac80211 also handle them so that we can send them further down the
stack into the drivers. We drop the old bss_color field and change iwlwifi
to use the new he_bss_color struct.
Signed-off-by: John Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20191217141921.8114-2-john@phrozen.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is a straight-forward conversion case for the new function, and
while we're at it, we can remove a null write to skb->next by replacing
it with skb_mark_not_on_list.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.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>
Print out the secure boot status, extended by the PCs of LMACs
and the UMAC. This needs to be before dumping, as dumping will
corrupt the PC (if the NMI is handled), so move that down.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Since v5.4-rc1 was released, iwlwifi started throwing errors when scan
commands were sent to the firmware with certain devices (depending on
the OTP burned in the device, which contains the list of available
channels). For instance:
iwlwifi 0000:00:14.3: FW error in SYNC CMD SCAN_CFG_CMD
This bug was reported in the ArchLinux bug tracker:
https://bugs.archlinux.org/task/64703
And also in a specific case in bugzilla, when the lar_disabled option
was set: https://bugzilla.kernel.org/show_bug.cgi?id=205193
Revert the commit that introduced this error, by using the number of
channels from the OTP instead of the number of channels that is
specified in the FW TLV that tells us how many channels it supports.
This reverts commit 06eb547c4a.
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Mehmet Akif Tasova <makiftasova@gmail.com>
[ Luca: reworded the commit message a bit. ]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This is an old parameter that was used supposed to be used only when
LAR was still under development. It should not be used anymore, but,
since it's available, end-users have been mangling with it
unnecessarily. In some cases it can cause problems because when LAR
is supported the driver and the firmware do not expect it to be
disabled.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When we transmit after TXQ dequeue, we aren't paying attention to
the return value of the transmit functions, leading to a potential
SKB leak.
Refactor the code a bit (and rename ..._tx to ..._tx_sta) to check
for this happening.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: cfbc6c4c5b ("iwlwifi: mvm: support mac80211 TXQs model")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
It used to be the case that if we got here, we wouldn't warn
but instead allocate the queue (DQA). With using the mac80211
TXQs model this changed, and we really have nothing to do with
the frame here anymore, hence the warning now.
However, clearly we missed in coding & review that this is now
a pure error path and leaks the SKB if we return 0 instead of
an indication that the SKB needs to be freed. Fix this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: cfbc6c4c5b ("iwlwifi: mvm: support mac80211 TXQs model")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The new API requires the driver to config the supported frame format
(legacy, HT, VHT etc.).
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The new API requires the driver to set the frame format
(legacy, HT, VHT etc.) to be used for the measurement.
The new API also supports 11az and secured measurement, but
these are not supported by the driver for now.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When receiving a new MCC driver get all the data about the new country
code and its regulatory information.
Mistakenly, we ignored the cap field, which includes global regulatory
information which should be applies to every channel.
Fix it.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
