Temporarily block EMLSR when scanning on a P2P Device interface,
as this is an indication that P2P activity is about to start, e.g.,
P2P client connection to a P2P GO.
Since a P2P scan while a station interface connection is active might
be long, increase the EMLSR blocking timeout to 10 seconds.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250612144708.85fb79d537fe.I27523f8d3f00f2b66f5f555f098e323be29465ea@changeid
If there is an ongoing scan that lasts long, the MPDU counters may not
increase enough due the device being busy with scanning and not
because we are in a low throughput scenario.
In that case we don't want to block EMLSR.
Instead, stop checking the counters from the moment we started
scanning, and when the scan ends - clear the counters and schedule a
check in 5 seconds, as usual.
Note that this is only done for regular scan since MLO scan is too short
to affect the counters, and scheduled scan is mainly used when we are
not connected.
Also note that we only stop checking whether to block EMLSR, and not if to
unblock.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250505215512.330ea440d19c.Ib10dae0b7a0cb0e10c59a9edf5ff7af0f065ac60@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Add a new device information 'info' substruct to the transport
that's const and can only be set by a special helper, and move
some information there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250503224232.cd80cb55403c.Ic18524b66d655fad734bf97192a54d9cfa9fdf1f@changeid
Generalize and extend the link pair tests to not just do
channel load checks, but generally check link pairs. To
enable more accurate checking, return the reasons bitmap
from iwl_mld_valid_emlsr_pair() and therefore rename it
to iwl_mld_emlsr_pair_state.
It's also necessary now to add more chandefs, and while
doing so fix the existing ones to be valid and add a
test to check they really are valid.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.1f7c4ac75c6d.I69d68359e02d99632e95daba3d126115dce167b3@changeid
Allow EMLSR if the bandwidths of the links are unequal if one of the
following conditions is true:
1. in low latency mode
2. bandwidth of the secondary link is greater than the bandwidth of the
primary
3. the primary link is active and is loaded enough to justify EMLSR
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250313002008.150c330711c4.Ifd72d2e076783991852a7f1756948b4f0efb9fea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The channel load logic moves from the FW to the driver.
- Implement the logic: allow EMLSR only if the candidate primary link is
active and if its average channel load exceeds the threshold.
- Remove IWL_MLD_EMLSR_BLOCKED_FW. Instead, treat ESR_RECOMMEND_LEAVE in
the EMLSR_RECOMMENDATION notif as an EXIT reason.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250313002008.6729a8d67815.Iab39bf0982d8cdbb0db701d31854101c2fcf3b64@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
According to the requirements, if the last scan isn't older than 20
seconds, we can use its results and do the link selection without
scanning before.
But this applies only when trying to get back to EMLSR, not if the link
has bad RSSI/missed beacons.
Since an MLO scan is cheap anyway, and results from 20 seconds before
are really old, always scan before links switching.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250309073442.a4c96e5c49d4.Ie55697af49435c2c45dccf7c607de5857b370f7a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwlwifi is the driver of all Intel wifi devices since 2008.
Since then, the hardware has changed a lot, but the firmware
API has changed even more. The need to keep one driver that
supports all those different APIs led us to introduce a new
architecture circa 2012 which allowed us to keep the same
interface to the hardware (DMAs, Tx queues, etc...) with a
new layer to implement the mid-layer between mac80211 and
the firmware. The first component is called the 'transport'
and the latter is called 'operation_mode' a.k.a op_mode.
In 2013 we took advantage of the new architecture to
introduce iwlmvm which allowed us to implement the, then,
new firmware API. This op_mode supports 7260 and up, those
devices supports support at least VHT.
Since then, wifi evolved and so did the firmware. It became
much bigger and took a lot of functionality from the driver.
It became increasingly hard to keep the same op_mode for the
newest devices and we experienced frequent regressions on
older devices. In order to avoid those regressions and keep
the code maintainable, we decided it was about time to start
a new op_mode.
iwlmld is a new op_mode that supports BE200 or newer if the
firmware being used is 97.ucode or newer. If the user has
an older devices or BE200 with .96.ucode, iwlmvm will be
loaded. Of course, this op_mode selection is seamless.
All the features supported in iwlmvm are supported in
iwlmld besides a few seldom used use cases: injection and
Hotspot 2.0. Those are under work.
A few points about the implementation:
* iwlmld doesn't have any mutexes, it relies on the
wiphy_lock
* iwlmld is more "resource oriented": stations, links and
interfaces are allocated and freed only after all the
relevant flows are completed.
* Firmware notifications' sizes are validated in a more
structured way.
We would love to see this new op_mode merged in 6.15. The
firmware for this new driver (.97.ucode) is not yet publicly
available but it'll be sent very soon.
People eager to get an early version of this firmware can
contact Emmanuel at:
emmanuel.grumbach@intel.com
I've listed the people who directly contributed
code, but many others from various teams have
contributed in other ways.
Co-developed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Co-developed-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Co-developed-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Co-developed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Co-developed-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Co-developed-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Co-developed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Co-developed-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://lore.kernel.org/linux-wireless/20250216094321.537988-1-miriam.rachel.korenblit@intel.com/
[fix Kconfig, fix api/phy.h includes, SPDX tag and coding
style issues, duplicated includes per 0-day robot]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
