Marek Vasut [Sat, 27 May 2023 22:28:59 +0000 (00:28 +0200)]
wifi: rsi: Do not set MMC_PM_KEEP_POWER in shutdown
It makes no sense to set MMC_PM_KEEP_POWER in shutdown. The flag
indicates to the MMC subsystem to keep the slot powered on during
suspend, but in shutdown the slot should actually be powered off.
Drop this call.
Fixes: 063848c3e155 ("rsi: sdio: Add WOWLAN support for S5 shutdown state") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527222859.273768-1-marex@denx.de
Marek Vasut [Sat, 27 May 2023 22:28:33 +0000 (00:28 +0200)]
wifi: rsi: Do not configure WoWlan in shutdown hook if not enabled
In case WoWlan was never configured during the operation of the system,
the hw->wiphy->wowlan_config will be NULL. rsi_config_wowlan() checks
whether wowlan_config is non-NULL and if it is not, then WARNs about it.
The warning is valid, as during normal operation the rsi_config_wowlan()
should only ever be called with non-NULL wowlan_config. In shutdown this
rsi_config_wowlan() should only ever be called if WoWlan was configured
before by the user.
Add checks for non-NULL wowlan_config into the shutdown hook. While at it,
check whether the wiphy is also non-NULL before accessing wowlan_config .
Drop the single-use wowlan_config variable, just inline it into function
call.
Fixes: 16bbc3eb8372 ("rsi: fix null pointer dereference during rsi_shutdown()") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527222833.273741-1-marex@denx.de
Neal Sidhwaney [Sat, 3 Jun 2023 06:00:23 +0000 (02:00 -0400)]
wifi: brcmfmac: Detect corner error case earlier with log
In brcmf_chip_recognition(), the return value from an MMIO read is
interpreted as various fields without checking if it failed, which is
harmless today, as the interpreted fields are checked for validity a
few lines below. However, in corner cases (on my MacbookPro 14,1,
sometimes after waking from sleep or soft reboot), when this happens,
it causes the logging to be misleading, because the message indicates
an unsupported chip type ("brcmfmac: brcmf_chip_recognition: chip
backplane type 15 is not supported"). This patch detects this case
slightly earlier and logs an appropriate message, with the same return
result as is the case today.
Zong-Zhe Yang [Fri, 2 Jun 2023 15:05:55 +0000 (23:05 +0800)]
wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (3 of 3)
Update TX power tables to RF version R63.
TX power tables' changes:
* TX power byrate:
tweak a bit
* TX power limit, TX power limit RU, TX power shape:
configure values for MEXICO, UKRAINE, CHILE, QATAR
tweak a bit on other configured values
* 6 GHz TX power limit, 6 GHz TX power limit RU:
add an extra dimension for 6 GHz regulatory power type, i.e.
STD (standard power), LPI (low power indoor), VLP (very low power)
Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz
regulatory power type.
Zong-Zhe Yang [Fri, 2 Jun 2023 15:05:54 +0000 (23:05 +0800)]
wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (2 of 3)
Update TX power tables to RF version R63.
TX power tables' changes:
* TX power byrate:
tweak a bit
* TX power limit, TX power limit RU, TX power shape:
configure values for MEXICO, UKRAINE, CHILE, QATAR
tweak a bit on other configured values
* 6 GHz TX power limit, 6 GHz TX power limit RU:
add an extra dimension for 6 GHz regulatory power type, i.e.
STD (standard power), LPI (low power indoor), VLP (very low power)
Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz
regulatory power type.
Zong-Zhe Yang [Fri, 2 Jun 2023 15:05:53 +0000 (23:05 +0800)]
wifi: rtw89: 8852c: update TX power tables to R63 with 6 GHz power type (1 of 3)
Update TX power tables to RF version R63.
TX power tables' changes:
* TX power byrate:
tweak a bit
* TX power limit, TX power limit RU, TX power shape:
configure values for MEXICO, UKRAINE, CHILE, QATAR
tweak a bit on other configured values
* 6 GHz TX power limit, 6 GHz TX power limit RU:
add an extra dimension for 6 GHz regulatory power type, i.e.
STD (standard power), LPI (low power indoor), VLP (very low power)
Besides, we adjust TX power handling at 6 GHz in phy to consider 6 GHz
regulatory power type.
Zong-Zhe Yang [Fri, 2 Jun 2023 15:05:51 +0000 (23:05 +0800)]
wifi: rtw89: regd: update regulatory map to R64-R40
Update notes:
According to Realtek Regulatory R40 and Realtek Channel Plan R64,
configure rtw89_regulatory mapping of 6 GHz for more countries and
adjust rtw89_regulatory mapping of 2/5 GHz for a few countries.
Zong-Zhe Yang [Fri, 2 Jun 2023 15:05:50 +0000 (23:05 +0800)]
wifi: rtw89: regd: judge 6 GHz according to chip and BIOS
We allow platform to disable 6 GHz on chips, which supports 6 GHz, through
BIOS. Driver will evaluate Realtek acpi DSM with RTW89_ACPI_DSM_FUNC_6G_DIS
(function 3) to get whether 6 GHz should be disabled.
Zong-Zhe Yang [Fri, 2 Jun 2023 15:05:49 +0000 (23:05 +0800)]
wifi: rtw89: refine clearing supported bands to check 2/5 GHz first
We refine to check if supported bands of NL80211_BAND_2GHZ and
NL80211_BAND_5GHZ exist before freeing their iftype_data. For
now, it does not really encounter problems because all current
chips support both 2 GHz and 5 GHz. But, driver actually allows
chips to declare whether 2/5 GHz are supported or not. In case
some future chips really don't support them, we refine this code.
Zong-Zhe Yang [Wed, 31 May 2023 06:07:13 +0000 (14:07 +0800)]
wifi: rtw89: 8851b: configure CRASH_TRIGGER feature for 8851B
RTL8851B firmware supports CRASH_TRIGGER feature from v0.29.41.0.
After this is configured, debugfs fw_crash can support type 1 on
RTL8851B to trigger firmware crash and verify L2 recovery through
simulation.
Zong-Zhe Yang [Wed, 31 May 2023 06:07:12 +0000 (14:07 +0800)]
wifi: rtw89: set TX power without precondition during setting channel
The key condition to check in wrapper of setting TX power is whether entity
is active or not. Before entity is active, we restrict TX power from being
set by outside callers, e.g. SAR/regulatory.
We mark entity as inactive when powering off MAC. Then, we will mark it as
active when we initialize HW channel stuffs after MAC power on. Although we
can get an active entity after leaving idle phase, TX power doesn't be set
well for default channel until stack set target channel for connection. It
causes that RF things cannot use better TX power during this interval.
Below are some cases which may encounter this or a similar situation.
* hw scan process before connection
As described above.
* right after restart hardware process (SER L2)
HW stuffs of target channel is initialized after mac80211 restart
hardware, but we unexpectedly need to wait one more command to set
channel again or to set TX power.
To fix it and improve RF behavior in that interval, during setting channel,
we don't need to check entity state before setting TX power, which actually
is used to restrict outside callers. It means we call chip ops directly to
replace the wrapper call. Then, TX power can be initialized as long as we
initialize/setup HW stuffs on one channel.
Besides, all chips should configure ops of setting TX power, so we remove
trivial check on pointer.
Zong-Zhe Yang [Wed, 31 May 2023 06:07:11 +0000 (14:07 +0800)]
wifi: rtw89: debug: txpwr table access only valid page according to chip
We now support RTL8851B which has only single RF path. For chip with
single RF path, TX power page is valid only in single path section.
So, we refine debugfs txpwr table to access TX power page according
to RF path number of runtime chip. It can prevent us from reading
beyond valid sections.
Po-Hao Huang [Wed, 31 May 2023 06:07:10 +0000 (14:07 +0800)]
wifi: rtw89: 8851b: enable hw_scan support
This enables hw_scan for 8851b after firmware version 0.29.37.1.
Extend the channel info struct with padding zeros so newer firmware
can work properly, this change is backward compatible with older
firmware.
Johannes Berg [Tue, 6 Jun 2023 12:49:29 +0000 (14:49 +0200)]
wifi: mac80211: use wiphy work for channel switch
Channel switch obviously must be handled per link, and we
have a (potential) deadlock when canceling that work. Use
the new delayed wiphy work to handle this instead and get
rid of the explicit timer that way too.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:28 +0000 (14:49 +0200)]
wifi: mac80211: use wiphy work for SMPS
SMPS requests are per link, and currently there's a potential
deadlock with canceling. Use the new wiphy work to handle SMPS
instead, so that the cancel cannot deadlock.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:27 +0000 (14:49 +0200)]
wifi: mac80211: unregister netdevs through cfg80211
Since we want to have wiphy_lock() for the unregistration
in the future, unregister also netdevs via cfg80211 now
to be able to hold the wiphy_lock() for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:25 +0000 (14:49 +0200)]
wifi: cfg80211: add a work abstraction with special semantics
Add a work abstraction at the cfg80211 level that will always
hold the wiphy_lock() for any work executed and therefore also
can be canceled safely (without waiting) while holding that.
This improves on what we do now as with the new wiphy works we
don't have to worry about locking while cancelling them safely.
Also, don't let such works run while the device is suspended,
since they'll likely need to interact with the device. Flush
them before suspend though.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:24 +0000 (14:49 +0200)]
wifi: cfg80211: hold wiphy lock when sending wiphy
Sending the wiphy out might cause calls to the driver,
notably get_txq_stats() and get_antenna(). These aren't
very important, since the normally have their own locks
and/or just send out static data, but if the contract
should be that the wiphy lock is always held, these are
also affected. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:23 +0000 (14:49 +0200)]
wifi: cfg80211: wext: hold wiphy lock in siwgenie
Missed this ioctl since it's in wext-sme.c where we
usually get via a front-level ioctl handler in the
other files, but it should also hold the wiphy lock
to align the locking contract towards the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:22 +0000 (14:49 +0200)]
wifi: cfg80211: move wowlan disable under locks
This is a driver callback, and the driver should be able
to assume that it's called with the wiphy lock held. Move
the call up so that's true, it has no other effect since
the device is already unregistering and we cannot reach
this function through other paths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:21 +0000 (14:49 +0200)]
wifi: cfg80211: hold wiphy lock in pmsr work
Most code paths in cfg80211 already hold the wiphy lock,
mostly by virtue of being called from nl80211, so make
the pmsr cleanup worker also hold it, aligning the
locking promises between different parts of cfg80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 12:49:20 +0000 (14:49 +0200)]
wifi: cfg80211: hold wiphy lock in auto-disconnect
Most code paths in cfg80211 already hold the wiphy lock,
mostly by virtue of being called from nl80211, so make
the auto-disconnect worker also hold it, aligning the
locking promises between different parts of cfg80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 7 Jun 2023 17:43:52 +0000 (19:43 +0200)]
Merge wireless into wireless-next
There are a number of upcoming things in both the stack and
drivers that would otherwise conflict, so merge wireless to
wireless-next to be able to avoid those conflicts.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Tue, 6 Jun 2023 13:28:05 +0000 (15:28 +0200)]
Revert "wifi: iwlwifi: update response for mcc_update command"
This reverts commit b70813e4a88f ("wifi: iwlwifi: update response
for mcc_update command") since it causes a merge conflict, and it
seems easier to redo the patch later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit 1bcbb1208e9a ("wifi: iwlwifi: mvm: FTM
initiator MLO support") as it causes a merge conflict, and
we can defer and re-do those changes later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Sun, 4 Jun 2023 09:11:28 +0000 (12:11 +0300)]
wifi: mac80211: stop warning after reconfig failures
If we have a reconfig failure in the driver, then we need
to shut down the network interface(s) at the network stack
level through cfg80211, which can result in a lot of those
"Failed check-sdata-in-driver check, ..." warnings, since
interfaces are considered to not be in the driver when the
reconfiguration fails, but we still need to go through all
the shutdown flow.
Avoid many of these warnings by storing the fact that the
stack experienced a reconfiguration failure and not doing
the warning in that case.
Johannes Berg [Sun, 4 Jun 2023 09:11:22 +0000 (12:11 +0300)]
wifi: mac80211: batch recalc during STA flush
When we flush stations, we first take them off the list
and then destroy them one by one. If we do the different
mode recalculations while destroying them, we cause the
following scenario:
- STA 1 has 80 MHz - min chanctx width is now 80 MHz
- STA 2 has 80 MHz
- empty STA list
- destroy STA 2
- recalc min chanctx width -> results in 20 MHz as
the STA list is already empty
This is broken, since as far as the driver is concerned
STA 1 still exists at this point, and this causes issues
at least with iwlwifi.
Fix - and also optimize - this by doing the recalc of
min chanctx width (and also P2P PS) only after all the
stations were removed.
Johannes Berg [Sun, 4 Jun 2023 09:11:20 +0000 (12:11 +0300)]
wifi: mac80211: recalc min chandef for new STA links
When adding a new link to a station, this needs to cause a
recalculation of the minimum chandef since otherwise we can
have a higher bandwidth station connected on that link than
the link is operating at. Do the appropriate recalc.
Mukesh Sisodiya [Sun, 4 Jun 2023 09:11:13 +0000 (12:11 +0300)]
wifi: mac80211: use u64 to hold enum ieee80211_bss_change flags
The size of enum ieee80211_bss_change is bigger that 32,
so we need u64 to be used in a flag. Also pass u64
instead of u32 to ieee80211_reconfig_ap_links() for the same
reason.
Johannes Berg [Thu, 4 May 2023 13:45:11 +0000 (16:45 +0300)]
wifi: mac80211: implement proper AP MLD HW restart
Previously, I didn't implement restarting here at all if the
interface is an MLD, so it only worked for non-MLO. Add the
needed code to restart an AP MLD correctly.
Johannes Berg [Thu, 4 May 2023 13:45:07 +0000 (16:45 +0300)]
wifi: mac80211_hwsim: avoid warning with MLO PS stations
If the station disables all links it's in powersave and
we shouldn't transmit anything to it, but we don't handle
that correctly yet. For now, just avoid the warning, once
we really add support for this case we can revert to the
old warning.
Gregory Greenman [Tue, 6 Jun 2023 07:43:10 +0000 (10:43 +0300)]
wifi: iwlwifi: pnvm: handle memory descriptor tlv
When PNVM is obtained from UEFI, there's an additional memory
descriptor TLV that has to be handled. It is the same TLV that
holds data in the reduced power tables. Also, in this TLV, the
actual data is located after address and size, so add the
corresponding offset.
Alon Giladi [Tue, 6 Jun 2023 07:43:06 +0000 (10:43 +0300)]
wifi: iwlwifi: Enable loading of reduce-power tables into several segments
Replace the field reduce_power_dram with a struct that holds data about
the reduced-power tables drams regions. Generalize load_payloads_segments()
to work for both pnvm tables and reduction power tables.
Make required adjustments in the data structures.
Alon Giladi [Tue, 6 Jun 2023 07:43:04 +0000 (10:43 +0300)]
wifi: iwlwifi: Separate loading and setting of power reduce tables
Take the part that copies the tables into DRAM, out of the method
that sets the prph_scratch to make the code cleaner. Each of the
operations will get more complex in the future when it will also
support larger power-reduce tables images.
Alon Giladi [Tue, 6 Jun 2023 07:43:03 +0000 (10:43 +0300)]
wifi: iwlwifi: Implement loading and setting of fragmented pnvm image
Save the pnvm payloads in several DRAM segments (not only in one as
used to). In addition, allocate a FW structure in DRAM that holds the
segments' addresses and forward its address to the FW. It's done when
FW has the capability to handle pnvm images this way (helps to process
large pnvm images).
Alon Giladi [Tue, 6 Jun 2023 07:43:00 +0000 (10:43 +0300)]
wifi: iwlwifi: Take loading and setting of pnvm image out of parsing part
Change iwl_pnvm_parse so it will only save the information into the
iwl_pnvm_image struct. This enables to use the parsing code for the
power reduce tables in the future.
Alon Giladi [Tue, 6 Jun 2023 07:42:59 +0000 (10:42 +0300)]
wifi: iwlwifi: Separate loading and setting of pnvm image into two functions
Take the part that is copying the pnvm image into DRAM, out of the
the method that sets the prph_scratch. Makes the code cleaner since
those 2 operations don't always happen together (loading should happen
only once while setting can happen more than once).
In addition, each operation will get more complex in the future when
it will support also larger pnvm images.
Alon Giladi [Tue, 6 Jun 2023 07:42:58 +0000 (10:42 +0300)]
wifi: iwlwifi: Generalize the parsing of the pnvm image
Generalize iwl_pnvm_parse(). This saves us from copying each payload
twice (first in the parsing and later when copying it to the dram).
Moreover, its more compatible for handling larger pnvm tables in
the future (in which payloads won't be concatenated).
The main changes are:
1. Take out the concatenating of the payloads from the parsing level
2. Start using iwl_pnvm_image structure that will hold pointers to
payloads that should be delivered to fw, their sizes and number.
Johannes Berg [Thu, 1 Jun 2023 06:52:46 +0000 (09:52 +0300)]
wifi: iwlwifi: mvm: tell firmware about per-STA MFP enablement
Indicate to the firmware for each station whether or not MFP
is used with this station. Note that we indicate MFP for it
before authorized since we don't know yet, and that will make
the firmware not handle should-be-protected management frames
without being able to check them.
Johannes Berg [Wed, 31 May 2023 16:50:05 +0000 (19:50 +0300)]
wifi: iwlwifi: mvm: remove warning for beacon filtering error
This warning is sometimes happening if we force a FW error
while disconnecting, which is annoying but harmless.
However, it's also pointless to throw a warning here, since
the stack and driver state doesn't really help, so just
remove that so the driver will ignore the error if any.
Haim Dreyfuss [Wed, 31 May 2023 16:49:59 +0000 (19:49 +0300)]
wifi: iwlwifi: mvm: offload BTM response during D3
There are mainly two types of BTM (BSS Transition Management)
requests, recommendations and notifications. For the first type,
a response is needed otherwise, most probably the STA will be
disconnected.
Since we don't want to wake up the host on it, set the BTM to reject
offload flag (if the device supports it) and rely on the FW to take
care of it. The FW will reject the BTM request and in case the AP
sends DEAUTH the FW can wake up the host to let it decide on the
next steps.
Benjamin Berg [Wed, 31 May 2023 16:49:58 +0000 (19:49 +0300)]
wifi: iwlwifi: do not log undefined DRAM buffers unnecessarily
DRAM buffers that are not defined in the TLVs (or are unused in the
preset) would cause a log message. To avoid confusion, skip processing
buffers with an invalid (i.e. uninitialized) DRAM path.
This further reduces the noise of the message in cases where it is
unlikely to be helpful. Also update a related debug log string to better
describe what is happening.
Abhishek Naik [Wed, 24 May 2023 17:42:11 +0000 (20:42 +0300)]
wifi: iwlwifi: update response for mcc_update command
Add support for the MCC update response version 8.
Versions 5-6 are already covered by the existing
flags conversion, and 7 isn't used.
The capabilities field in iwl_mcc_update_resp is 32 bits
wide now, and the flags moved, so some more changes are
needed.
While at it, convert the flags to bool (to avoid having
to deal with BIT(16) specially etc.) and use the
struct_size() macro for the memory allocation.
Johannes Berg [Wed, 24 May 2023 17:42:09 +0000 (20:42 +0300)]
wifi: iwlwifi: mvm: remove useless code
Setting the station to -EBUSY was originally done under
this lock, and the comment still refers to it. But this
no longer happens because that was removed when DQA was
removed. Remove the leftover code as well.
Gregory Greenman [Wed, 24 May 2023 17:42:06 +0000 (20:42 +0300)]
wifi: iwlwifi: mvm: adjust csa notifications and commands to MLO
In the following notifications and commands mac_id was replaced
with link_id:
* CANCEL_CHANNEL_SWITCH_CMD
* CHANNEL_SWITCH_START_NOTIF
* CHANNEL_SWITCH_ERROR_NOTIF
The logic around was not changed, so only adjust handling
mac/link id.
Emmanuel Grumbach [Wed, 24 May 2023 17:42:05 +0000 (20:42 +0300)]
wifi: iwlwifi: mvm: update the FW apis for LINK and MAC commands
The firmware added new fields to be able to pass the link_id as the AP
knows it and the esr_transition_timeout.
For now, pass only the link_id since we don't have access to the
esr_transition_timeout yet.
Haim Dreyfuss [Wed, 24 May 2023 17:42:03 +0000 (20:42 +0300)]
wifi: iwlwifi: don't silently ignore missing suspend or resume ops
In case the driver doesn't implement suspend or resume operations
on the transport layer, notify the driver's upper layer.
Otherwise, we might access d3_status uninitialized.
Avraham Stern [Wed, 24 May 2023 17:42:02 +0000 (20:42 +0300)]
wifi: iwlwifi: mvm: support PASN for MLO
When adding a PASN station, the non MLD API was used. This results
in assert when operating as MLD. Fix it to use the MLD API when
operating as MLD. For now, the default link is used for the added
station.
Gustavo A. R. Silva [Fri, 2 Jun 2023 19:42:47 +0000 (13:42 -0600)]
wifi: iwlwifi: mvm: Fix -Warray-bounds bug in iwl_mvm_wait_d3_notif()
kmemdup() at line 2735 is not duplicating enough memory for
notif->tid_tear_down and notif->station_id. As it only duplicates
612 bytes: up to offsetofend(struct iwl_wowlan_info_notif,
received_beacons), this is the range of [0, 612) bytes.
Fix this by allocating space for the whole notif object and zero out the
remaining space in memory after member station_id.
This also fixes the following -Warray-bounds issues:
CC drivers/net/wireless/intel/iwlwifi/mvm/d3.o
drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function ‘iwl_mvm_wait_d3_notif’:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2743:30: warning: array subscript ‘struct iwl_wowlan_info_notif[0]’ is partly outside array bounds of ‘unsigned char[612]’ [-Warray-bounds=]
2743 | notif->tid_tear_down = notif_v1->tid_tear_down;
|
from drivers/net/wireless/intel/iwlwifi/mvm/d3.c:7:
In function ‘kmemdup’,
inlined from ‘iwl_mvm_wait_d3_notif’ at drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2735:12:
include/linux/fortify-string.h:765:16: note: object of size 612 allocated by ‘__real_kmemdup’
765 | return __real_kmemdup(p, size, gfp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function ‘iwl_mvm_wait_d3_notif’:
drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2744:30: warning: array subscript ‘struct iwl_wowlan_info_notif[0]’ is partly outside array bounds of ‘unsigned char[612]’ [-Warray-bounds=]
2744 | notif->station_id = notif_v1->station_id;
| ^~
In function ‘kmemdup’,
inlined from ‘iwl_mvm_wait_d3_notif’ at drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2735:12:
include/linux/fortify-string.h:765:16: note: object of size 612 allocated by ‘__real_kmemdup’
765 | return __real_kmemdup(p, size, gfp);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Link: https://github.com/KSPP/linux/issues/306 Fixes: 905d50ddbc83 ("wifi: iwlwifi: mvm: support wowlan info notification version 2") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/ZHpGN555FwAKGduH@work Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, whenever an EMA beacon is formed, due to is_template
argument being false from the caller, the switch count is always
decremented once which is wrong.
Also if switch count is equal to profile periodicity, this makes
the switch count to reach till zero which triggers a WARN_ON_ONCE.
Don't do link address translation for beacons and probe responses,
this leads to reporting multiple scan list entries for the same AP
(one with the MLD address) which just breaks things.
We might need to extend this in the future for some other (action)
frames that aren't MLD addressed.
Johannes Berg [Sun, 4 Jun 2023 09:11:16 +0000 (12:11 +0300)]
wifi: mac80211: mlme: fix non-inheritence element
There were two bugs when creating the non-inheritence
element:
1) 'at_extension' needs to be declared outside the loop,
otherwise the value resets every iteration and we
can never really switch properly
2) 'added' never got set to true, so we always cut off
the extension element again at the end of the function
This shows another issue that we might add a list but no
extension list, but we need to make the extension list a
zero-length one in that case.
Fix all these issues. While at it, add a comment explaining
the trim.