linux.git/drivers/net/wireless/intel, branch v6.7-rc2

wifi: iwlwifi: fix system commands group ordering

2023-11-12T19:34:19+00:00

The commands should be sorted inside the group definition.
Fix the ordering so we won't get following warning:
WARN_ON(iwl_cmd_groups_verify_sorted(trans_cfg))

Link: https://lore.kernel.org/regressions/2fa930bb-54dd-4942-a88d-05a47c8e9731@gmail.com/
Link: https://lore.kernel.org/linux-wireless/CAHk-=wix6kqQ5vHZXjOPpZBfM7mMm9bBZxi2Jh7XnaKCqVf94w@mail.gmail.com/
Fixes: b6e3d1ba4fcf ("wifi: iwlwifi: mvm: implement new firmware API for statistics")
Tested-by: Niklāvs Koļesņikovs 
Tested-by: Damian Tometzki 
Acked-by: Kalle Valo 
Signed-off-by: Miri Korenblit 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Linus Torvalds

wifi: ipw2x00: replace deprecated strncpy with strscpy_pad

2023-10-23T17:26:29+00:00

strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.

`extra` is intended to be NUL-terminated which is evident by the manual
assignment of a NUL-byte as well as its immediate usage with strlen().

Moreover, many of these getters and setters are NUL-padding buffers with
memset():
2439  |	memset(&tx_power, 0, sizeof(tx_power));
9998  | memset(sys_config, 0, sizeof(struct ipw_sys_config));
10084 | memset(tfd, 0, sizeof(*tfd));
10261 | memset(&dummystats, 0, sizeof(dummystats));
... let's maintain this behavior and NUL-pad our destination buffer.

Considering the above, a suitable replacement is `strscpy_pad` due to
the fact that it guarantees both NUL-termination and NUL-padding on the
destination buffer.

To be clear, there is no bug in the current implementation as
MAX_WX_STRING is much larger than the size of the string literals being
copied from. Also, strncpy() does NUL-pad the destination buffer and
using strscpy_pad() simply matches that behavior. All in all, there
should be no functional change but we are one step closer to eliminating
usage of strncpy().

Do note that we cannot use the more idiomatic strscpy invocation of
(dest, src, sizeof(dest)) as the destination buffer cannot have its size
determined at compile time. So, let's stick with (dest, src, LEN).

Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt 
Reviewed-by: Kees Cook 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20231017-strncpy-drivers-net-wireless-intel-ipw2x00-ipw2200-c-v2-1-465e10dc817c@google.com

wifi: ipw2x00: fix format-truncation warnings

2023-10-23T17:24:39+00:00

On v6.6-rc4 with GCC 13.2 I see:

drivers/net/wireless/intel/ipw2x00/ipw2100.c:5905:63: warning: '%s' directive output may be truncated writing up to 63 bytes into a region of size 32 [-Wformat-truncation=]
drivers/net/wireless/intel/ipw2x00/ipw2100.c:5905:9: note: 'snprintf' output between 4 and 140 bytes into a destination of size 32
drivers/net/wireless/intel/ipw2x00/ipw2200.c:10392:63: warning: '%s' directive output may be truncated writing up to 63 bytes into a region of size 32 [-Wformat-truncation=]
drivers/net/wireless/intel/ipw2x00/ipw2200.c:10392:9: note: 'snprintf' output between 4 and 98 bytes into a destination of size 32

Fix this by copying only the firmware version and not providing any extra
information via ethtool. This is an ancient driver anyway and most likely
removed soon so it doesn't really matter.

Compile tested only.

Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20231012135854.3473332-2-kvalo@kernel.org

wifi: iwlwifi: drop NULL pointer check in iwl_mvm_tzone_set_trip_temp()

2023-10-23T10:50:21+00:00

Since 'tz_device' is an in-place member of 'struct iwl_mvm', it can't
be NULL and so relevant check may be dropped. Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Dmitry Antipov 
Acked-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231003092048.24998-1-dmantipov@yandex.ru
Signed-off-by: Johannes Berg

wifi: iwlwifi: bump FW API to 86 for AX/BZ/SC devices

2023-10-23T10:49:30+00:00

Start supporting API version 86 for new devices.

Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231022173519.e2f720799600.I6e22188a47efe0cbb4e013259955c4019843799f@changeid
Signed-off-by: Johannes Berg

wifi: iwlwifi: read DSM func 2 for specific RF types

2023-10-23T10:49:30+00:00

By definition, this DSM func is valid only for HR/JF RF types.
Until now firmware ignored this bit (if set) on other than the
above types, but in future firmware versions sending this bit
will lead to firmware 0x3426 assert.
Avoid that by verifying the HW in driver first.

Signed-off-by: Daniel Gabay 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231022173519.eec3b5d6152f.Ibc7ffe5ef1c156d878f1300c6059c6c91b374114@changeid
Signed-off-by: Johannes Berg

wifi: iwlwifi: mvm: show dump even for pldr_sync

2023-10-23T10:49:30+00:00

Worst case it's extra (garbage) data, best case we see why
things failed ... Seems the trade-off is better if we print
it.

Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231022173519.30e614ecd540.I47324f555ebcf22d0dd0afa94e7ca0af53a9fdba@changeid
Signed-off-by: Johannes Berg

wifi: iwlwifi: mvm: cycle FW link on chanctx removal

2023-10-23T10:49:30+00:00

When the vif is in MLD mode, we'll get a vif links change from
non-zero to zero on disassociation, which removes all links in
the firmware and adds the 'deflink' the driver/mac80211 has.
This causes the firmware to clear some internal state.

However, in non-MLD mode, this doesn't happen, and causes some
state to be left around in firmware, which can particularly
cause trouble with the ref-BSSID in multi-BSSID, leading to an
assert later if immediately making a new multi-BSSID connection
with a different ref-BSSID.

Fix this by removing/re-adding the link in the non-MLD case
when the channel is removed from the vif. This way, all of the
state will get cleared out, even if we need the deflink, which
is more for software architecture purposes than otherwise.

Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231022173519.90c82837ba4d.I341fa30c480f7673b14b48a0e29a2241472c2e13@changeid
Signed-off-by: Johannes Berg

wifi: iwlwifi: trace full frames with TX status request

2023-10-23T10:49:30+00:00

If upper layers requested a TX status, then the frames are
more important, so trace frames in that case.

Signed-off-by: Johannes Berg 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231022173519.0dfb60a2eaec.I3c3e46ed0eb05700a4d05d293f80d727354a402f@changeid
Signed-off-by: Johannes Berg

wifi: iwlwifi: empty overflow queue during flush

2023-10-23T10:49:30+00:00

If a TX queue has no space for new TX frames, the driver will keep
these frames in the overflow queue, and during reclaim flow it
will retry to send the frames from that queue.
But if the reclaim flow was invoked from TX queue flush, we will also
TX these frames, which is wrong as we don't want to TX anything
after flush.
This might also cause assert 0x125F when removing the queue,
saying that the driver removes a non-empty queue
Fix this by TXing the overflow queue's frames only if we are
not in flush queue flow.

Fixes: a44509805895 ("iwlwifi: move reclaim flows to the queue file")
Signed-off-by: Miri Korenblit 
Signed-off-by: Gregory Greenman 
Link: https://lore.kernel.org/r/20231022173519.caf06c8709d9.Ibf664ccb3f952e836f8fa461ea58fc08e5c46e88@changeid
Signed-off-by: Johannes Berg