Age | Commit message (Collapse) | Author | Files | Lines |
|
Do not call iwl_mvm_mld_get_primary_link if only one link
is active.
In that case, the sole active link should be used.
iwl_mvm_mld_get_primary_link returns -1 if only one link
is active causing a warning.
Fixes: 8c9bef26e98b ("wifi: iwlwifi: mvm: d3: implement suspend with MLO")
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240311081938.6c50061bf69b.I05b0ac7fa7149eabaa5570a6f65b0d9bfb09a6f1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.9
The fourth "new features" pull request for v6.9 with changes both in
stack and in drivers. The theme in this pull request is to fix sparse
warnings but we still have some left in wireless subsystem. Otherwise
quite normal.
Major changes:
rtw89
* NL80211_EXT_FEATURE_SCAN_RANDOM_SN support
* NL80211_EXT_FEATURE_SET_SCAN_DWELL support
rtw88
* support for more rtw8811cu and rtw8821cu devices
mt76
* mt76x2u: add Netgear WNDA3100v3 USB
* mt7915: newer ADIE version support
* mt7925: radio temperature sensor support
* mt7996: remove GCMP IGTK offload
* tag 'wireless-next-2024-03-08' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (125 commits)
wifi: rtw89: wow: move release offload packet earlier for WoWLAN mode
wifi: rtw89: wow: set security engine options for 802.11ax chips only
wifi: rtw89: update suspend/resume for different generation
wifi: rtw89: wow: update config mac function with different generation
wifi: rtw89: update DMA function with different generation
wifi: rtw89: wow: update WoWLAN status register for different generation
wifi: rtw89: wow: update WoWLAN reason register for different chips
wifi: brcm80211: handle pmk_op allocation failure
wifi: rtw89: coex: Add coexistence policy to decrease WiFi packet CRC-ERR
wifi: rtw89: coex: When Bluetooth not available don't set power/gain
wifi: rtw89: coex: add return value to ensure H2C command is success or not
wifi: rtw89: coex: Reorder H2C command index to align with firmware
wifi: rtw89: coex: add BTC ctrl_info version 7 and related logic
wifi: rtw89: coex: add init_info H2C command format version 7
wifi: rtw89: 8922a: add coexistence helpers of SW grant
wifi: rtw89: mac: add coexistence helpers {cfg/get}_plt
wifi: cw1200: restore endian swapping
wifi: wlcore: sdio: Rate limit wl12xx_sdio_raw_{read,write}() failures warns
wifi: rtlwifi: Remove rtl_intf_ops.read_efuse_byte
wifi: rtw88: 8821c: Fix false alarm count
...
====================
Link: https://lore.kernel.org/r/20240308100429.B8EA2C433F1@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In MLO, we need the link id in the GTK key to be given by
the driver after rekeying in wowlan, so add that.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228094500.ce1bfc83a680.I43a6f8ab2804ee07116a37d5b9ec601b843464b1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Cross-merge networking fixes after downstream PR.
Conflicts:
net/mptcp/protocol.c
adf1bb78dab5 ("mptcp: fix snd_wnd initialization for passive socket")
9426ce476a70 ("mptcp: annotate lockless access for RX path fields")
https://lore.kernel.org/all/20240228103048.19255709@canb.auug.org.au/
Adjacent changes:
drivers/dpll/dpll_core.c
0d60d8df6f49 ("dpll: rely on rcu for netdev_dpll_pin()")
e7f8df0e81bf ("dpll: move xa_erase() call in to match dpll_pin_alloc() error path order")
drivers/net/veth.c
1ce7d306ea63 ("veth: try harder when allocating queue memory")
0bef512012b1 ("net: add netdev_lockdep_set_classes() to virtual drivers")
drivers/net/wireless/intel/iwlwifi/mvm/d3.c
8c9bef26e98b ("wifi: iwlwifi: mvm: d3: implement suspend with MLO")
78f65fbf421a ("wifi: iwlwifi: mvm: ensure offloading TID queue exists")
net/wireless/nl80211.c
f78c1375339a ("wifi: nl80211: reject iftype change with mesh ID change")
414532d8aa89 ("wifi: cfg80211: use IEEE80211_MAX_MESH_ID_LEN appropriately")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
At that point in the code mvm->mutex has already been taken, so jump to
out_noreset in order to unlock before returning the error.
Fixes: 8c9bef26e98b ("wifi: iwlwifi: mvm: d3: implement suspend with MLO")
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.21de6e68d9e5.I3c0ebe577dec6b26ab6b4eac48035d6f35a8b0f8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
To support wider-bandwidth OFDMA we need to configure the
PHY context in the firmware, which will in turn configure
the DSP accordingly. Pass the relevant information down.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.ca666ede5dd6.I357972823d20e9045e2c97dbb7ac24fe9f5a6e41@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The resume code path assumes that the TX queue for the offloading TID
has been configured. At resume time it then tries to sync the write
pointer as it may have been updated by the firmware.
In the unusual event that no packets have been send on TID 0, the queue
will not have been allocated and this causes a crash. Fix this by
ensuring the queue exist at suspend time.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.6632e6dc7b35.Ie6e6a7488c9c7d4529f13d48f752b5439d8ac3c4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
With C99 bool we really also should use true/false, not the
upper-case variants, wherever they may actually be coming
from. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240208185302.5732dd306ee9.Ifc07c026ac3779429e3dc949e96c9437e89f7bf9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In MFP, do not disconnect if an unprotected deauth
or disassoc was received during D3.
For that, need to configure wowlan with MFP (IS_11W_ASSOC).
Now, in case of an unprotected deauth/disassoc, the wakeup
reason returned by the firmware will be:
IWL_WAKEUP_BY_11W_UNPROTECTED_DEAUTH_OR_DISASSOC
(and not IWL_WOWLAN_WAKEUP_BY_DISCONNECTION_ON_DEAUTH
which will cause a disconnection).
Also, report this reason to cfg80211.
In another patch, the driver will send an SA query.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.fde438a22e3f.I3c8497520aaa95a22febff727b0ad08146965d47@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The firmware (later) actually uses the values even for keys
that are invalid as far as the host is concerned, later in
rekeying, and then only sets the low 48 bits since the PNs
are only 48 bits over the air. It does, however, compare the
full 64 bits later, obviously causing problems.
Remove the memset and use kzalloc instead to avoid any old
heap data leaking to the firmware. We already init all the
other fields in the struct anyway. This leaves the data set
to zero for any unused fields, so the firmware can look at
them safely even if they're not used right now.
Fixes: 79e561f0f05a ("iwlwifi: mvm: d3: implement RSC command version 5")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240206175739.462101146fef.I10f3855b99417af4247cff04af78dcbc6cb75c9c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
After waking from D3, we set the iPN given by the firmware.
For some reason, CIPHER_SUITE_AES_CMAC was missed.
That caused copying garbage to the iPN - causing false replays.
(since 'seq' is on the stack, and the iPN from the firmware
was not copied into it, it contains garbage which later is
copied to the iPN key).
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.2be5b35be30f.I99db8700d01092d22a6d76f1fc1bd5916c9df784@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If during D3 there was both a GTK rekey and a
disconnection, when waking up, we must first
update the new keys and then disconnect.
The reason is that when disconnecting we first need
to remove the keys.
Trying to remove invalid keys results in firmware
assert.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.68cf3974b5d7.Iac9b71a1906ab973aba9baadc9e923b63c0b4945@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
With unlimited pseudo-D3, we can get stuck here in the read if
the firmware never wakes up. All of our testing infrastructure
however will anyway give up after at most a minute, so there's
no value in that.
Limit this to about a minute to avoid getting stuck with the
RTNL held forever, which basically makes the machine unusable
and then we can't even understand what caused the failure.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.ca55b3a7fa8d.Id746846f187442ebc689416d2688f2bd9278c0e9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When waking from D3 (and a GTK rekey happened during
D3), the key itself is saved in iwl_wowlan_status_data::gtk
array, but the PN is saved in iwl_wowlan_status_data::gtk_seq
array.
The indices (of the same key) might differ in both arrays.
Fix using the gtk array index in the gtk_seq array.
Rather, iterate and search for the correct key in the
gtk_seq array.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.bdd0511c007d.I3325288c64c010a4d008ac4429de1c2b14ef764c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When using MLO, we need to have only a single link active
when entering suspend and of course most of the code also
needs to be adjusted to not use deflink, apart from older
code that's not used with MLO-capable firmware. Implement
that.
Note that the link selection currently prefers the "best"
link, which might really not be the best for D3, but that
can be fixed later once we agree.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240131091413.38f0fd4d2db0.I27c7a1d08aecc5da0af2c351212f22e92ed70219@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The IPN is reported by the firmware in 6 bytes little endian,
but mac80211 expects big endian so it can do memcmp() on it.
We used to store this as a u64 which was filled in the right
way, but never used. When implementing that it's used, we
changed it to just be 6 bytes, but lost the conversion. Add
it back.
Fixes: 04f78e242fff ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240129211905.138ed8a698e3.I1b66c386e45b5392696424ec636474bff86fd5ef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If there was a rekey failure during D3 when firmware is
handling the GTK rekeying, and it decided that we should
wake up, then there was an issue in the connection and
we don't necessarily have the right keys, so we should
disconnect.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240128084842.944af193d479.I5ef9f1f0e048d44d7158615d071b793d69eceb75@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Now with the mac80211 locking model changed, we no longer can
cause any bad dependencies here between mvm->mutex and other
mutexes in mac80211, so we no longer need to drop the mutex
early or even temporarily. Clean this up.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20231219215605.1f2f5289ecc6.I7e3b8e806b6d50e88ba0c26767da8261806eb9c7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In order to get regulatory domain, driver sends MCC_UPDATE_CMD to the
FW. One of the parameters in the response is the status which can tell
if the regdomain has changed or not.
When iwl_mvm_init_mcc() is called during iwl_op_mode_mvm_start(), then
sband is still NULL and channel parameters (i.e. chan->flags) cannot be
initialized. When, further in the flow, iwl_mvm_update_mcc() is called
during iwl_mvm_up(), it first checks if the regdomain has changed and
then skips the update if it remains the same. But, since channel
parameters weren't initialized yet, the update should be forced in this
codepath. Fix that by adding a corresponding parameter to
iwl_mvm_init_fw_regd().
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20231017115047.78b2c5b891b0.Iac49d52e0bfc0317372015607c63ea9276bbb188@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
During the D3 resume flow, all new rekeys are passed from the FW.
Because the FW supports only one IGTK at a time, every IGTK rekey
update should be done by removing the last IGTK. The mvmvif holds a
pointer to the last IGTK for that reason and thus should be updated
when a new IGTK is passed upon resume.
Fixes: 04f78e242fff ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow")
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20231017115047.8ceaf7e5ece7.Ief444f6a2703ed76648b4d414f12bb4130bab36e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This new version of wolan_info_notif supports the handling
of bigtk during d3, this patch holds parsing of the new
notif version, adding new keys and updating ipn of
existing keys during the resume flow.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230921110726.4ebcd244f436.Ib507573d50fa0ac666d09ab71f5241ccbcd7cd00@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
As part of the new security API in the FW, all security keys are to
be removed before station removal. Until now IGTK rekey
wasn't supported in the D3 resume flow, and thus the driver might
not know the right key to remove.
If an IGTK was rekeyed during D3 the old IGTK is removed and the
new key is updated. If not, the old key's IPN is updated.
As opposed to GTK, which both the FW and the driver hold it's two
most recent keys, only one IGTK is held.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230621144844.b53c301c07e6.I375277a10a1f756b93d4a343f6664351a80189c5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When resuming from D3 the two most recent GTKs are passed from
the FW with wowlan_info_notif. Both keys should be updated as
they both might be needed upon FW restart and they both should
be removed upon station removal.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230621144844.3ea3a9f52ec2.I7cedfa2bb0eafb83e7c77363673560acf05bff74@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In the D3 resume flow, use two different iterating functions
to go over the old keys and update the new ones
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230621144844.a2442844c224.I598ed742c7aaa5414702f03f694f2dc0874bc077@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
kmemdup() at line 2735 is not duplicating enough memory for
notif->tid_tear_down and notif->station_id. As it only duplicates
612 bytes: up to offsetofend(struct iwl_wowlan_info_notif,
received_beacons), this is the range of [0, 612) bytes.
2735 notif = kmemdup(notif_v1,
2736 offsetofend(struct iwl_wowlan_info_notif,
2737 received_beacons),
2738 GFP_ATOMIC);
which evidently does not cover bytes 612 and 613 for members
tid_tear_down and station_id in struct iwl_wowlan_info_notif.
See below:
$ pahole -C iwl_wowlan_info_notif drivers/net/wireless/intel/iwlwifi/mvm/d3.o
struct iwl_wowlan_info_notif {
struct iwl_wowlan_gtk_status_v3 gtk[2]; /* 0 488 */
/* --- cacheline 7 boundary (448 bytes) was 40 bytes ago --- */
struct iwl_wowlan_igtk_status igtk[2]; /* 488 80 */
/* --- cacheline 8 boundary (512 bytes) was 56 bytes ago --- */
__le64 replay_ctr; /* 568 8 */
/* --- cacheline 9 boundary (576 bytes) --- */
__le16 pattern_number; /* 576 2 */
__le16 reserved1; /* 578 2 */
__le16 qos_seq_ctr[8]; /* 580 16 */
__le32 wakeup_reasons; /* 596 4 */
__le32 num_of_gtk_rekeys; /* 600 4 */
__le32 transmitted_ndps; /* 604 4 */
__le32 received_beacons; /* 608 4 */
u8 tid_tear_down; /* 612 1 */
u8 station_id; /* 613 1 */
u8 reserved2[2]; /* 614 2 */
/* size: 616, cachelines: 10, members: 13 */
/* last cacheline: 40 bytes */
};
Therefore, when the following assignments take place, actually no memory
has been allocated for those objects:
2743 notif->tid_tear_down = notif_v1->tid_tear_down;
2744 notif->station_id = notif_v1->station_id;
Fix this by allocating space for the whole notif object and zero out the
remaining space in memory after member station_id.
This also fixes the following -Warray-bounds issues:
CC drivers/net/wireless/intel/iwlwifi/mvm/d3.o
drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function ‘iwl_mvm_wait_d3_notif’:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2743:30: warning: array subscript ‘struct iwl_wowlan_info_notif[0]’ is partly outside array bounds of ‘unsigned char[612]’ [-Warray-bounds=]
2743 | notif->tid_tear_down = notif_v1->tid_tear_down;
|
from drivers/net/wireless/intel/iwlwifi/mvm/d3.c:7:
In function ‘kmemdup’,
inlined from ‘iwl_mvm_wait_d3_notif’ at drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2735:12:
include/linux/fortify-string.h:765:16: note: object of size 612 allocated by ‘__real_kmemdup’
765 | return __real_kmemdup(p, size, gfp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function ‘iwl_mvm_wait_d3_notif’:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2744:30: warning: array subscript ‘struct iwl_wowlan_info_notif[0]’ is partly outside array bounds of ‘unsigned char[612]’ [-Warray-bounds=]
2744 | notif->station_id = notif_v1->station_id;
| ^~
In function ‘kmemdup’,
inlined from ‘iwl_mvm_wait_d3_notif’ at drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2735:12:
include/linux/fortify-string.h:765:16: note: object of size 612 allocated by ‘__real_kmemdup’
765 | return __real_kmemdup(p, size, gfp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Link: https://github.com/KSPP/linux/issues/306
Fixes: 905d50ddbc83 ("wifi: iwlwifi: mvm: support wowlan info notification version 2")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/ZHpGN555FwAKGduH@work
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If we do get multiple notifications from firmware, then
we might have allocated 'notif', but don't free it. Fix
that by checking for duplicates before allocation.
Fixes: 4da46a06d443 ("wifi: iwlwifi: mvm: Add support for wowlan info notification")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230418122405.116758321cc4.I8bdbcbb38c89ac637eaa20dda58fa9165b25893a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Clang static analysis reports this issue
d3.c:567:22: warning: The left operand of '>' is
a garbage value
if (seq.tkip.iv32 > cur_rx_iv32)
~~~~~~~~~~~~~ ^
seq is never initialized. Call ieee80211_get_key_rx_seq() to
initialize seq.
Fixes: 0419e5e672d6 ("iwlwifi: mvm: d3: separate TKIP data from key iteration")
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.6dd372f84f93.If1f708c90e6424a935b4eba3917dfb7582e0dd0a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
As part of version 2 we don't need to have wake_packet_bufsize
and wake_packet_length. The first one is already calculated by the driver,
the latter is sent as part of the wake packet notification.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413213309.3b53213b10d4.Ibf2f15aca614def2d262dd267d1aad65931b58f1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In MLO, some fields of iwl_mvm_vif should be defined in the
context of a link. Define a separate structure for these fields and
add a deflink object to hold it as part of iwl_mvm_vif. Non-MLO legacy
code will use only deflink object while MLO related code will use the
corresponding link from the link array.
It follows the strategy applied in mac80211 for introducing MLO
changes.
The below spatch takes care of updating all driver code to access
fields separated into MLD specific data structure via deflink (need
to convert all references to the fields listed in var to deflink.var
and also to take care of calls like iwl_mvm_vif_from_mac80211(vif)->field).
@iwl_mld_vif@
struct iwl_mvm_vif *v;
struct ieee80211_vif *vv;
identifier fn;
identifier var = {bssid, ap_sta_id, bcast_sta, mcast_sta,
beacon_stats, smps_requests, probe_resp_data,
he_ru_2mhz_block, cab_queue, phy_ctxt,
queue_params};
@@
(
v->
- var
+ deflink.var
|
fn(vv)->
- var
+ deflink.var
)
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230328104948.4896576f0a9f.Ifaf0187c96b9fe52b24bd629331165831a877691@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This was missed when this function was refactored out of
iwl_mvm_wowlan_program_keys.
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20221205102808.746f40250502.Ieef45ffc617726cb47b3a4ec625d513d16082f4b@changeid
|
|
This notification replaces the WOWLAN_GET_STATUSES command-and-response,
so it's required to parse all the keys in the notification just like
what happened when that command was used.
Move around a few required static functions in order to avoid forward
declarations.
Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.ca3fb23cab81.I0a9fe7729af4567b98813bc51bad13ee5512a0ae@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
In recent patches notifications based d3 resume flow was added,
and the resume flow was changed.
Currently, when resuming from d3 during which an assert was thrown,
the resume flow skips the iteration over active interfaces
preventing the sta to reconnect to the ap.
Perform the iteration in case an assert was thrown to fix it.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.ad888cc6cd91.Ib56e416fce17df089edf76d22896430df5ebe080@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
We have recently enabled resume flow based on notifications.
These notifications are sent by the FW when completing the resume flow.
From IWL_DEVICE_FAMILY_AX210 the resume flow is triggered by the
transport layer on iwl_trans_d3_resume.
On IWL_DEVICE_FAMILY_22000 and earlier we trigger the resume flow by
sending the D0I3 command.
Currently, we are waiting for the notifications before sending the
command, the notifications won't be sent by the FW since there is no
resume trigger to piggyback on.
Send the command before starting the wait flow to fix it.
Signed-off-by: Haim, Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.5f0f251edf9c.Ia49ab73105af6f52aa7d318f4984edecd3b0671a@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
To support FW versions that send the scan match information as
an asynchronous notification.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.bbc5602d0b6f.I1329c231f82e7bf18f7dba0ccbd9f2d4080cbfc1@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
We have recently added support for resume based on notifications.
Enable it.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.a6344ba23df5.I09fce8cf5aac1d46b40ae81b1abcf7a0e54af196@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
Due to IMR, when host returns from hibernate, commands cannot
be sent as part of the resume flow, and so after ending
d3 the FW needs to send notifications instead of responses.
This notification indicates whether a fw reset is required.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.898ecba881b2.I13eb69bb5af08b9ac33043647eaed6b8d50e8659@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
The wowlan info notification is quite big.
(~750 bytes without the wake packet itself).
The max FW notification size is ~2K.
There might be cases where the wake packet gets truncated because of
this limit.
Separating the wake packet from the wowlan info notification allows us to
get more data without trimming it.
Note: we currently limit the wake packet to 1600 bytes.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.06d1e6aecf10.Ib3d6a46ffe71d10cbc69bdb5654e6b14c28df245@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
IMR (Isolated Memory Regions) is a mechanism to protect memory regions
from unwarranted access by agents in the system that should not have access
to that memory.
When IMR is enabled, pages in the DRAM will be located within the IMR
memory space, accessible only by the device.
As a side effect, during S4 (a.k.a hibernate) the IMR memory space
is not retained.
While the DRAM is saved to the disk and restored by the OS upon resume,
the IMR, which is hidden from the OS neither saved upon suspend nor
restored upon resume.
As a consequence of the above, it turned out that commands cannot
be sent as part of the resume flow, and so after ending
d3 the FW needs to use notifications instead of cmd-resp.
The resume flow becomes asynchronous, with a series
of notifications, starting with wowlan_info_notif, through
wowlan_pkt_notif and complete the resume flow by d3_end_notif.
This patch adds the support for wowlan info notification.
The wake packet has been removed from the wowlan info struct
and will be handled in a dedicated notification.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.3ce8deefd929.Ieba8610e8bb4bec788076371ae38becb4a3d20d5@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
This code is dead, even old FW versions don't use it.
The IWL_D0I3_RESET_REQUIRE flag will be sent by the FW via a notification,
instead of command, the notification handler will be introduced later
in the series.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220906161827.87c82482229a.I70456c38ed8f7beb7d62dd618f58e7dc0a7d33b2@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
|
|
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We anyway don't differentiate between the errors so it is pointless,
returning NULL will be simpler in this case.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20220517120044.78a7651327bb.I77480de7c26db850680f96a3440fb6a1b45dd9d2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Since commit a05829a7222e ("cfg80211: avoid holding the RTNL when
calling the driver") we're not only holding the RTNL when going
in and out of suspend, but also the wiphy->mtx. Add that to the
D3 test debugfs in iwlwifi since it's required for various calls
to mac80211.
Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220129105618.fcec0204e162.Ib73bf787ab4d83581de20eb89b1f8dbfcaaad0e3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Avoid void pointer arithmetic since it's technically
undefined and causes warnings in some places that use
our code.
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.20220128153014.e349104ecd94.Iadc937f475158b9437becdfefb361a97e7eaa934@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When enabling W=3 that gets us -Wcast-qual, fix those warnings
in the code and propagate constness properly, or cast it away
via (uintptr_t) where really needed.
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.20220128153014.4ac2f19c121e.Ied9469d93f8199206242bfba96e4e8d1949e3a08@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Instead of taking the group/command separately, make the function
take a combined command ID. In many cases, this allows us to pass
an existing command ID (e.g. cmd.id), or introduce a new variable
for it, so that we don't use the command ID twice.
This way, we can also use LONG_GROUP implicitly, so we don't need
to spell that out for many commands.
Apart from mvm.h, fw/img.{c,h} changes and some copyright and
indentation updates, this was done with spatch:
@@
identifier cmd;
expression fw, G, C, def;
@@
struct iwl_host_cmd cmd = {
.id = WIDE_ID(G, C),
...
};
...
-iwl_fw_lookup_cmd_ver(fw, G, C, def)
+iwl_fw_lookup_cmd_ver(fw, cmd.id, def)
@@
identifier cmd;
expression fw, C, def;
@@
struct iwl_host_cmd cmd = {
.id = C,
...
};
...
-iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def)
+iwl_fw_lookup_cmd_ver(fw, cmd.id, def)
@@
identifier func;
expression fw, G, C, mvm, flags, cmd, size, def;
type rettype;
@@
rettype func(...)
{
+u32 cmd_id = WIDE_ID(G, C);
...
-iwl_fw_lookup_cmd_ver(fw, G, C, def)
+iwl_fw_lookup_cmd_ver(fw, cmd_id, def)
...
-iwl_mvm_send_cmd_pdu(mvm, WIDE_ID(G, C), flags, cmd, size)
+iwl_mvm_send_cmd_pdu(mvm, cmd_id, flags, cmd, size)
...
}
@@
identifier func;
expression fw, G, C, mvm, flags, cmd, size, def;
type rettype;
@@
rettype func(...)
{
+u32 cmd_id = C;
...
-iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def)
+iwl_fw_lookup_cmd_ver(fw, cmd_id, def)
...
-iwl_mvm_send_cmd_pdu(mvm, C, flags, cmd, size)
+iwl_mvm_send_cmd_pdu(mvm, cmd_id, flags, cmd, size)
...
}
@@
expression fw, C, def;
@@
-iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def)
+iwl_fw_lookup_cmd_ver(fw, C, def)
@@
expression fw, C, G, def;
@@
-iwl_fw_lookup_cmd_ver(fw, G, C, def)
+iwl_fw_lookup_cmd_ver(fw, WIDE_ID(G, C), def)
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.20220128153014.c4ac213cef5c.I6fd9a4fcbcf16ef3a3ae20a2b08ee54ebe06f96f@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Newer firmware versions are going to come with a new version
of the wowlan status API, which gives us replay counters for
both GTKs that might still be in use, as well as unifying the
layout of the counters to just be 64-bit quantities.
Extend our code to handle this case and be able to install
replay counters for both keys, if they're sent up from the
firmware.
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.20211204083238.73637acafe0b.I33e27712a12fff2816edc0a8abda1759259e20d7@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Move the GTK rekeying condition into iwl_mvm_set_key_rx_seq()
so we can modify it in the next patch. In the next firmware
API revision we'll properly get data for both active GTKs and
will have to install it accordingly.
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.20211204083238.f309942ddd15.Iaa95c602f3a681dd464e10ce2de047aa86fac19c@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Trying to convert from one firmware data representation to the
next version is getting tedious and error-prone, and doesn't
lend itself well to new APIs being added. Additionally, the
version 11 of the API as defined in the driver doesn't even
exist in the firmware.
Instead of converting to a newer firmware version of the data,
convert to an internal representation. This takes a bit more
space because the TKIP/AES counters etc. must be kept twice,
their representation is different and we don't know which of
the ones it is until later, but this is just a temporary use
of memory, and the code is clearer this way.
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.20211024181719.9e71630627f3.Iad975e15338844ca068683f62a51eb1fcb69e608@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|