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 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>
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>
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>
Issuing a system suspend command raises the following warning:
WARNING: CPU: 0 PID: 15 at drivers/mmc/core/sdio.c:1042 mmc_sdio_suspend+0xd4/0x19c
CPU: 0 PID: 15 Comm: kworker/u2:1 Not tainted 6.7.0-rc1-wt+ #710
Hardware name: Atmel SAMA5
Workqueue: events_unbound async_run_entry_fn
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x48
dump_stack_lvl from __warn+0x98/0x160
__warn from warn_slowpath_fmt+0xcc/0x140
warn_slowpath_fmt from mmc_sdio_suspend+0xd4/0x19c
mmc_sdio_suspend from mmc_bus_suspend+0x50/0x70
mmc_bus_suspend from dpm_run_callback+0xe4/0x248
dpm_run_callback from __device_suspend+0x234/0x91c
__device_suspend from async_suspend+0x24/0x9c
async_suspend from async_run_entry_fn+0x6c/0x210
async_run_entry_fn from process_one_work+0x3a0/0x870
[...]
This warning is due to a check in SDIO core ensuring that interrupts do not
remain enabled for cards being powered down during suspend. WILC driver
currently does not set the MMC_PM_KEEP_POWER flag, so disable interrupt
when entering resume.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-6-c2f766d0988c@bootlin.com
WILC1000 suspend/resume implementation is currently composed of two parts:
suspend/resume ops implemented in cfg80211 ops, which merely sets a
flag, and suspend/resume ops in sdio/spi driver which, based on this flag,
execute or not the suspend/resume mechanism. This dual set of ops is not
really needed , so keep only the sdio part to implement suspend/resume.
While doing so, remove the now unused suspend_event flag.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-5-c2f766d0988c@bootlin.com
host_wakeup_notify and host_sleep_notify are surrounded by chip_wakeup and
chip_allow_sleep calls, which theorically need to be protected with the
hif_cs lock. This lock protection is currently missing. Instead of adding
the lock where those two functions are called, move those in host->chip
suspend notifications to benefit from the lock already used there (in
bus_acquire/bus_release)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-2-c2f766d0988c@bootlin.com
Driver systematically disables some power mechanism each time it starts the
chip firmware (so mostly when interface is brought up). This has a negative
impact on some specific scenarios when the chip is exposed as a
hotpluggable SDIO card (eg: WILC1000 SD):
- when executing suspend/resume sequence while interface has been brought
up
- rebooting the platform while module is plugged and interface has been
brought up
Those scenarios lead to mmc core trying to initialize again the chip which
is now unresponsive (because of the power sequencer setting), so it fails
in mmc_rescan->mmc_attach_sdio and enter a failure loop while trying to
send CMD5:
mmc0: error -110 whilst initialising SDIO card
mmc0: error -110 whilst initialising SDIO card
mmc0: error -110 whilst initialising SDIO card
[...]
Preventing the driver from disabling this "power sequencer" fixes those
enumeration issues without affecting nominal operations.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240613-wilc_suspend-v1-1-c2f766d0988c@bootlin.com
wlcore firmware versions are structured thusly:
chip.if-type.major.sub-type.minor
e.g. 8 9 0 0 58
With WL18xx ignoring the major firmware version, looking for a
firmware version that conforms to:
chip >= 8
if-type >= 9
major (don't care)
sub-type (don't care)
minor >= 58
Each test is satisfied if the value read from the firmware is greater
than the minimum, but if it is equal (or we don't care about the
field), then the next field is checked.
Thus it doesn't recognise 8.9.1.x.0 as being newer than 8.9.0.x.58
since the major and sub-type numbers are "don't care" and the minor
needs to be greater or equal to 58.
We need to change the major version from "ignore" to "0" for this later
firmware to be correctly detected, and allow the dual-firmware version
support to work.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/E1sBsyH-00E8w6-Vu@rmk-PC.armlinux.org.uk
wlcore_fw_status() is passed a pointer to the struct wl_fw_status to
decode the status into, which is always wl->fw_status. Rather than
referencing wl->fw_status within wlcore_fw_status(), use the supplied
argument so that we access this member in a consistent manner.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/E1sBsxx-00E8vi-Gf@rmk-PC.armlinux.org.uk
