For different MACs we maintain the configs in different
files, and while it's a small waste of space, this is a
worthwhile trade-off for maintenance and simplicity. So
allow different MAC types to have the same config. This
could allow the same config for two MACs in the same MAC
family, but that's not hugely important. Also simplify
the test to not build a config list, there's no good
reason to do that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.27f5d570eb32.I1649309a0e54a1d446a38c5b2124a582de9f6d61@changeid
No hardware that uses iwlmvm actually supports HT greenfield.
Remove the support and then clean up the v1 rate API by doing
a conversion to v2 rate API, the only thing v1 covered that
couldn't be done in v2 was HT greenfield.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.805ec090c61f.Iafd87f62ceb463b72f861a5348078999dcaace92@changeid
This is ephemeral data that's passed from the alive
response to the PNVM loading, so it doesn't need to
be stored. Pass it around instead.
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/20250504132447.fe8be4454007.I24824f35620b21fe49e9243818c7188e431af48e@changeid
This really belongs there, it's needed early, so move it. Remove
the related but dead iwl_trans_pcie_ctx_info_gen3_set_step() while
at it. In iwlmld move the calls since they do part of the trans
configuration.
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/20250504132447.a4681ee11dd7.I6434a13d51932e984bb07695bc1cb931ebdcd27c@changeid
Instead of having a trans_configure method that copies all
the data, just have the users set up the configuration in
the transport directly. This simplifies the code on both
sides. While doing so also move some value from the trans
struct into the conf struct because they are configuration.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250504132447.e2a2535ecfd0.I21653103ff02afc5a4d97a41b68021f053985e37@changeid
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
We pass this parameter around a lot of places just to
validate what the firmware told us against the hardware
with a warning, which seems to never trigger. Remove it.
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.5405014d7f88.I3b74a1fd51a39c6df5674f2994189092d1635e7f@changeid
The rate validation in mac80211 considers a rate to be valid iff both
the rate index and the count are positive. When the rate scaling is
managed in the driver and not enough traffic passed to set the actual
rate, the driver set the rate to be the optimal rate. However, the rate
count is not set and thus the rate is considered not valid. Fix it by
setting the count to 1.
Fixes: 3e99b4d282 ("wifi: mac80211: Sanity check tx bitrate if not provided by driver")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250503224232.0d1d1e022d63.I76833c14ba1d66f9bea5c32b25a54d8b36f229ba@changeid
The code currently passes only the specific image that should
be loaded, but then has to pass the IML (image loader) out of
band, which is confusing. Pass the full FW data together with
desired image type, and use the IML from that.
This also cleans up the code in the various sub-drivers a bit
as they no longer have to look up and check for the image.
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/20250503224231.eac4006e81c5.Iebadc56bb2762e5f4d71f66bb2609d74b33daf11@changeid
FW sends new notification version 2 indicating whether activating EMLSR
mode is recommended or not. If recommendation is to leave EMLSR or force
leave then FW sends the reason. Add debug log for the reason sent by FW.
Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250503224231.0582726248a4.I9d1d00eb98d10a3a742cb3e06665ce10e5ec93f0@changeid
Simplify the logic here by tracking only suspended as a
status bit, and remove CMD_SEND_IN_D3 completely. There
is no value, since the op-mode sets the state and also
sends the commands.
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/20250503224231.cc3360761f1e.I72261afc42cee8983198b4660b7d38b7df7963da@changeid
There's no reason for pcie code to call itself indirectly,
directly use the pcie functions instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Yedidya Ben Shimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.52db0b9fba15.I062e766ded86f61ec86104c28b84767f1c29ea78@changeid
Since there are two bytes hole in struct iwl_dev_info, add
a subdev_mask to match with. Also, since the PCI IDs list
needs to match first, and the dev-info list is matched from
the bottom up, remove unnecessary entries.
With this, even though there are new entries from previous
changes, the overall size is slightly reduced.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.689f9b335cbe.I66f1344b6ac7aa3665696637c97fa843c2307423@changeid
A long time ago, when transport vs. device configs were
introduced, we wanted to eventually have a list of PCI
IDs and a separate list of devices, but for simplicity
embedded the transport config in the whole config, and
it all got confusing.
Finish splitting that out. Doing so requires having more
IWL_DEV_INFO() entries, but the whole trans/cfg aliasing
goes away and the code becomes a lot simpler.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.e03f65c0f693.I076a997f800db455b575008f9488b151738ad7ec@changeid
Remove the erroneously named IWL_DEVICE_BZ_COMMON macro
from the Sc file and fix some indentation. Also bump the
minimum FW version since it's not released yet anyway,
right now this is mostly to make the config different
from iwl_bz_cfg which would otherwise be the same with
the upcoming transport config cleanups.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.b313d54b8809.Ia975b6d5460996f2a2761dd3d0fef4a56f1f3e24@changeid
It's not clear that it makes sense to have any matches
for IWL_CFG_ANY for this bit, but let's assume for now
that this makes sense. Then, it's clearer to call this
BW_NOT_LIMITED rather than BW_NO_LIMIT, since the last
change.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.9b39693b505c.Ib47aa6a072a0e61bbba28383ce54764cd859f19c@changeid
The BW limit, cores and RF ID are matched in the subdevice ID,
so it doesn't really make sense to have both SUBDEV() match and
a match on any of those three. In particular, for Killer devices
the subdevice ID doesn't even follow the layout, so no matching
should be on those three values at all, only with SUBDEV().
Change the logic around the BW limit to have it more like all
the other things: only a bw_limit match in the dev_info, and
put the actual bandwidth into struct iwl_cfg. This duplicates a
number of those values, but that way the logic is clearer.
Add a test that checks that the three matches mentioned above
are not used in conjunction with SUBDEV(), and check that if
the bw_limit is matched, a BW limit is provided in the config.
Also check that the "Killer" devices have a SUBDEV() match.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.a185eac2736c.I87ee87300c92518a1d3296d3eda9fd4163e9085e@changeid
This really is the same device as covered by iwl_cfg_bz,
just the discrete version. Since discrete vs integrated
is handled in the transport config, there's no need to
have both. Remove iwl_cfg_gl.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.fbb78183dc85.Ic5429009677ae1023cf1f43a655e90409a30c493@changeid
This was used in some really old devices, and then got
carried forward to Qu devices, even though on those we
don't need it at all since the TX aggregation start is
offloaded to the firmware. Remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.9c2689e2ca8e.I8274b29ca64d9ef9d1e357bbe34ca3a4b97aeb7a@changeid
Now that the fw_name_mac is no longer around and derived
from the MAC type automatically, we no longer need to have
different configurations for Qu/QuZ. Combine them. For the
killer AX1650s/i, also fix the names, there was a mixup.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.957fbb5437ce.If51ad0b2c8afaaa131208125af3bc292793613bb@changeid
