When EMLSR exits due to beacon loss on the current link, the driver
should keep the link that is still receiving beacons. The previous
code always called get_primary_link(), keeping the primary link
regardless of which link is actually losing beacons. If the primary
link is the one losing beacons, the driver exits EMLSR onto the
degraded link and the connection is lost eventually.
When both links lose beacons, keep the primary link. When only the
current link loses beacons -- whether due to signal loss or a BSS
parameter change -- keep the other link.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260517100550.b2d700f7775e.I8e9189ce6cf4388878beab14e56341becd5f427c@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
When FW PHY statistics report high channel load (MCLM), the driver
triggers an internal MLO scan to find a better link. However, link grade
computation uses the QBSS Load IE from AP beacons, not MCLM data. If
the AP does not broadcast a QBSS Load IE, the scan produces no benefit
as the grade falls back to static band defaults regardless, and the same
bad link will be selected anyway as the active link.
Skip the MLO scan trigger when the AP does not advertise a QBSS Load IE.
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260517100550.621538e20244.I7fdccb759508f32991cc06774cc7621725a58bd3@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
This fixes a kernel panic in reconfig failure:
1. we have a BSS connection
2. we have a NAN connection
3. FW error occurs
4. reconfig restores the BSS connection
5. however, restoring the NAN connection fails due to a FW error.
6. erroneously, ieee80211_handle_reconfig_failure is called and marks all
interfaces as not-in-driver (will be fixed in a different patch).
7. mac80211 frees the links of the BSS connection but doesn't tell the
driver about that, as it thinks that this vif is not in the driver.
8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed
(erroneously?)
9. Therefore, async_handlers_wk is being executed, processing the
statistics notification that was received after we restored the BSS
connection.
10. the notification handler dereferences fw_id_to_bss_conf[id], which is
now a dangling pointer, as mac80211 already freed this link in (7).
11. On the first access to one of the links fields, we panic.
While this can and should be fixed by removing the call to
ieee80211_handle_reconfig_failure in (6), it is also not a good idea to
carry and maybe handle notifications from a dead FW.
We do purge the notifications when we stop the FW, but in reconfig
failure we stop the FW too late, after the notifications are processed.
In addition, async_handlers_wk can always be scheduled before the
reconfig work.
Purge the notifications immediately when transport notifies about a nic
error.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.4414228bf1d1.I1926a2b2e7827eaac22882699880ec04a3cb95f0@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
iwl_mld_cancel_async_notifications does 2 things: it purges the list of
notifications and flushes the async_handlers_wk.
We call iwl_mld_cancel_async_notifications after we stopped or suspended
the fw. So in that stage we don't expect any new notification coming,
and if erroneously there are new notifications coming, the work will be
queued again anyway, so the flush is pretty much pointless.
iwl_mld_cancel_async_notifications will need to be called in a context
w/o the wiphy lock held, and the only reason why this function requires
the lock being held is for flushing the work.
Remove the flush.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260517100550.70dddca96191.I06d3c6433ec22f81f2fb3fb2ee43881e662c5212@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The FW API doesn't allow a station (of certain types, including
STATION_TYPE_PEER) to not be correlated to any link. Therefore,
when switching links, mac80211 first adds the new link and then
removes the old one.
In case we have a NAN interface that operates on 3 links and a
BSS interface that operates on the 4th link, there won't be any
room to perform a link switch that temporarily needs two links
for the BSS interface, but the firmware only has four total.
To mitigate this, try to evacuate a NAN channel in this scenario:
First try to evacuate a NAN channel using the same phy as the BSS
link being deactivated, since we expect NAN to follow the BSS
channel configuration. If that doesn't work, try to evacuate any
NAN channel.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260515150751.a193c0f41b1f.I1d56c8d8d61d110422271971843b71a93f5ec354@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
For NAN data, the supplicant may derive and install GTKs to
transmit with. As multicast data encryption is supported only
with firmware versions that support adding NAN multicast
data station, allow GTK installation only with such FW
versions. Otherwise, do not install the GTK to the device.
For NAN management, there are no GTKs, but there are IGTKs
and BIGTKs, which need to be installed for the NAN broadcast
and NAN management stations. This is supported only with
firmware versions that allow adding NAN broadcast station
and NAN management station.
Handle both of these cases by adjusting the station mask
appropriately, returning a zero station mask for the GTK
and allowing that to not be an error/warning message.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Co-developed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260513084215.7e18e0718d22.Icbf4204a9f1190eb4102016ad5f1c5bdab49635b@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The FW added a new station type to allow NAN multicast
data to be transmitted. The queue of the station is
opened by the firmware when all the NAN Peer NDI stations
associated with the NDI are scheduled at the same time.
Add the corresponding support in iwlmld:
- When a NAN data interface is added, add a NAN multicast
data station and allocate a queue to it.
- When a NAN data interface is removed, remove the NAN
multicast station.
- On the Tx path, when a multicast data frame is received
on a NAN data interface, direct it to the NAN multicast
data queue.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260513084215.1d8e3463717d.I57deaea42bce9afee63f284a57eb8755485e7ea8@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
A firmware API of a mix and match (MAC + RF) is the lower one of the
two. But the MODULE_FIRMWARE of QU/QUZ/SO/MA/TY with GF/HR, was defined
using the max API of GF/HR, which is 100, instead of the max API of
QU/QUZ/SO/MA/TY, which are API 77/89.
Therefore, the wrong firmware files were published in the modinfo,
leading to missing firmware files.
Fix this by using the right API when declaring MODULE_FIRMWARE.
While at it, add a IWL_FW_AND_PNVM entry for SO and GF4, that was
missing.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20260513084215.c8dcacbeb616.I3d51a9daeda6fb7f52b3014101db79fdc98295d5@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
The following limitations arise from the current FW support for NAN:
- While NAN synchronization and discovery beacons are sent
internally by the firmware, the BIGTK is configured to the
auxiliary station associated with the NAN operation. Thus,
the beacons are transmitted unprotected.
- The auxiliary station cannot be configured with support for
management frame protection as this is not supported by the
firmware. Thus, there is no way to protect the SDFs and the
NAFs.
To overcome the above limitations the firmware introduced the
following new station types:
- NAN broadcast station: Used for NAN synchronization and
discovery. i.e., used for beacon transmissions. A BIGTK
can be configured to this station and thus beacons can
be transmitted with protection.
- NAN management station: Used for sending SDFs and NAFs.
This station can be configured with support for management
frame protection etc.
Modify the iwlmld logic to support the older and the newer
firmware designs. As no Tx queue is needed for the NAN
broadcast station, modify the internal station support
to allow adding/removing a station without a queue. In
addition, since no links are associated with these stations,
modify the internal station support to allow adding a station
without a link mask.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260512222731.692bf627811d.I7170dbaa28a74519c012e2d7818e2999819dc478@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
uAPSD is transitioning to a certification-only feature. The new
firmware API version 3 removes advanced uAPSD fields, keeping only
basic parameters needed for certification testing.
Support the new VER_3 API in the MLD driver while maintaining
backward compatibility with VER_1/2. The MVM driver continues
using VER_2 only. Remove the obsolete PSM_UAPSD_AP_MISBEHAVING_NOTIFICATION
notification from the MLD driver
Signed-off-by: Avinash Bhatt <avinash.bhatt@intel.com>
Link: https://patch.msgid.link/20260512222731.96b6f53c8708.I4f01b97b25d91ebb1561845d7925103e274574fa@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
