This causes unnecessary error level kernel messages if the platform
does not have any UATS table.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.306b7eed8671.I6e9294335378dab38ef957866a0d39ec1a2df7f8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Kalle reported that this triggers very occasionally, but
we don't even know which place, except that it wasn't one
with a warning. Make all of them warnings since this is
really not meant to happen and indicates driver bugs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.be7a3a95afae.Ie8606d36783818c043c971bf0bc6f4df6a6e8f5b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since we always block EMLSR for ROC, we also need to always
unblock it, even if we don't have a P2P device interface.
Fix this.
Fixes: a1efeb8230 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.96bbf98b716d.Id5a36954f8ebaa95142fd3d3a7a52bab5363b0bd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is
normally called with input from the firmware, so it should use
IWL_FW_CHECK() instead of WARN_ON().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.4ea8fb7c47d4.I1c22af213f97f69bfc14674502511c1bc504adfb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the firmware has MLD APIs, it will handle all timing and we
don't need to give it timestamps. Therefore, we don't care about
the timestamps stored in the BSS table, so there's no need to
flush the BSS table.
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/20240625194805.c6d86dc2377e.I246d0fae0d23ed34b7cd9c3400edb004eb5ac1d0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
LNL is the codename for the upcoming Series 2 Core Ultra
processors designed by Intel. AX101, AX201 and AX203 devices
are not shiped on LNL platforms, so don't support them.
Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240613171043.f24a228dfd96.I989a2d3f1513211bc49ac8143ee4e9e341e1ee67@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When UATS isn't enabled (no VLP/AFC AP support), we need to still
set the right bits in the channel/regulatory flags, so remove the
uats_enabled argument to the parsing etc.
Also, firmware deals just fine with getting the UATS table if it
supports the command even if the bits aren't set, so always send
it, since it's also needed if BIT(31) is set, but the driver need
not have any knowledge of that. Remove 'uats_enabled' entirely.
Fixes: 0d2fc8821a ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618195731.a81e7234c4f6.Ic0131180d38e0f1ead2f7fa0e7583407ceaa0bd1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This isn't related to whether or not "fw can be loaded",
but rather requesting that ME go into a state where doing
a product reset is safe. This is related to FW load only
in the specific case of where it's used today in iwlmvm,
notably when it's known that the firmware itself will (or
at least may) do a product reset during load.
Clarify the documentation.
I was tempted to rename things too, but on the ME side it
really is also called PLDR (which is a Windows term and
may not even match the complete behaviour since doing a
full product reset from the driver also requires calling
an ACPI method first.) So keep the name aligned with ME.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618194245.ca2c55121a04.I889cd47210367ca9110411472ee696b796a37ab5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
PLDR (product level device reset) is a Windows term, and
is something the driver triggers there, AFAICT.
Really what 'pldr_sync' here wants to capture is whether
or not the firmware will/may do a product reset during
initialization, which makes the device drop off the bus,
requiring a rescan. If this is the case, obviously the
init will fail/time out, so we don't want to report all
kinds of errors etc., hence this tracking variable.
Rename it to 'fw_product_reset' to capture the meaning
better.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618194245.ccf849642af8.I01dded6b2393771b7baf8b4b17336784d987c7c2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When setting the keys for secure measurement with an AP the station
is associated with, the TK should only be referenced and not copied.
In addition set the cipher only when the correct station is found.
Fixes: 626be4bf99 ("wifi: iwlwifi: mvm: modify iwl_mvm_ftm_set_secured_ranging() parameters")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618194245.be2a5327554d.Ie53220b075dacb23a8d073f6008aafd339368592@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_trans_pcie_gen2_fw_alive doesn't use the scd_addr parameter,
it was there only because we needed the functio to have a prototype same
as iwl_trans_ops::fw_alive callback.
But now the ops is removed so no reason to keep the parameter.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20240618194245.1aa8bf13aea9.I9662c10c1db545dd8849af4bb4ab47708d4548d8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will allow to suspend / resume the system without resetting the
firmware. This will allow to reduce the resume time.
In case the fast_resume fails, stop the device and bring it up from
scratch.
Raise the timeout for the D3_END notification since in some iterations,
it took 240ms.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618194245.03b8d2801044.I613d17c712de7a0d611cde4e14f37ebbe0c3c964@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix incorrect use of _tx_ valid ant data in the function.
Fixes: 4ea1ed1d14 ("wifi: iwlwifi: mvm: support set_antenna()")
Signed-off-by: Daniel Gabay <daniel.gabay@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/20240618200104.b7c6a320c7dc.I3092eb5275056f2162b9694e583c310c38568b2a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
AP interfaces fundamentally cannot leave the channel, so multi-
channel operation with them isn't really possible. We shouldn't
advertise support for such, at least not as long as we don't
have full multi-radio support. Thus, remove the AP bit from the
interface combinations for two channels and add another set for
just one channel that has it.
Also, to avoid duplicating everything even more, unify the NAN
and non-NAN cases.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618200104.3213638262ef.I2a0031b37623d7763fd0c5405477ea7206a3e923@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Do not access legacy bits for new devices, this has no effect.
Somehow, wowlan worked despite the usage of the wrong bits. Now
that we want to keep the firmware loaded during suspend even without
wowlan, this change is needed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618200104.399d4d215210.Id12e7fdb7bab9f2c4c0d292519b5c1b4753a8c84@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Call the tracing function even if the cfg80211 callbacks
are not set. This would allow better understanding of
user space actions.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20240614093541.018cb816e176.I28f68740a6b42144346f5c175c7874b0a669a364@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When updating a channel context, the code can apply wider
bandwidth TDLS STA channel definitions to each and every
channel context used by the device, an approach that will
surely lead to problems if there is ever more than one.
Restrict the wider BW TDLS STA consideration to only TDLS
STAs that are actually related to links using the channel
context being updated.
Fixes: 0fabfaafec ("mac80211: upgrade BW of TDLS peers when possible")
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240612143707.1ad989acecde.I5c75c94d95c3f4ea84f8ff4253189f4b13bad5c3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In channel switch without an additional channel context,
where the reassign logic kicks in, we also need to update
the station bandwidth and chandef minimum width correctly
to avoid having station rate control configured to wider
bandwidth than the channel context. Do that now.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240612143418.0bc3d28231b3.I51e76df86212057ca0469e235ba9bf4461cbee75@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Make ieee80211_chan_bw_change() able to use the reserved chanreq
(really the chandef part of it) for the calculations, so it can
be used _without_ applying the changes first. Remove the comment
that indicates this is required, since it no longer is. However,
this capability only gets used later.
Also, this is not ideal, we really should not different so much
between reserved and non-reserved usage, to simplify. That's a
further cleanup later though.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240612143418.1a08cf83b8cb.Ie567bb272eb25ce487651088f13ad041f549651c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We'll need this function to take a new chandef in
(some) channel switching cases, so prepare for that
by allowing that to be passed and using it if so.
Clean up the code a little bit while at it.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240612143418.772313f08b6a.If9708249e5870671e745d4c2b02e03b25092bea3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Public action extended channel switch announcement (ECSA)
frames cannot be protected well, the spec is unclear about
what should happen in the presence of stations that can
receive protected dual and stations that cannot.
Mitigate these issues by not treating public action frames
as the absolute truth, only treat them as a hint to stop
transmitting (quiet mode), and do the remainder of the CSA
handling only when receiving the next beacon (or protected
action frame) that contains the CSA; or, if it doesn't,
simply stop being quiet and continue operating normally.
This limits the exposure to malicious ECSA public action
frames, since they cannot cause a disconnect now, only a
short interruption in traffic.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240612143037.ec7ccc45903e.Ife17d55c7ecbf98060f9c52889f3c8ba48798970@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
HDMI Tx needs HDMI Tx memory power domain turned on. This power domain is
handled under the VPU power domain.
The HDMI Tx currently works because it is enabling the PD by directly
poking the power controller register. It is should not do that but properly
use the power domain controller.
Fix this by adding the power domain to HDMI Tx.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20240625145017.1003346-3-jbrunet@baylibre.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Replace the incorrect reference to the v4l2_subdev_enable_stream()
function with the correct v4l2_subdev_enable_streams() spelling.
Fixes: d0749adb30 ("media: v4l2-subdev: Add subdev .(enable|disable)_streams() operations")
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://lore.kernel.org/r/20240619225343.15873-1-laurent.pinchart@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
FW_LOADER config only selects the firmware loader API, but we also need
the sysfs_upload symbols for firmware_upload_unregister() and
firmware_upload_register() to function properly.
Fixes: 7a52ab415b ("media: i2c: Add driver for THine THP7312")
Cc: stable@vger.kernel.org
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Link: https://lore.kernel.org/r/20240620102544.1918105-1-kory.maincent@bootlin.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The recent fix for Lenovo IdeaPad 330-17IKB replaced the quirk entry,
and this eventually breaks the existing quirk for Lenovo Yoga Duet 7
13ITL6 equipped with the same PCI SSID 17aa:3820.
For applying a proper quirk for each model, check the codec SSID
additionally. Fortunately Yoga Duet has a different codec SSID,
0x17aa3802.
(Interestingly, 17aa:3802 has another conflict of SSID between another
Yoga model vs 14IRP8 which we had to work around similarly.)
Fixes: b1fd0d1285 ("ALSA: hda/realtek: Enable headset mic on IdeaPad 330-17IKB 81DM")
Link: https://patch.msgid.link/20240625155217.18767-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
