Always rely on 'driver_is_goingto_unload' of 'struct rtl_hal'
and remove (presumably misused) 'driver_going2unload' from it.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230605100700.111644-1-dmantipov@yandex.ru
Remove 'struct rtl_dualmac_easy_concurrent_ctl' of 'struct rtl_priv'
and related code in '_rtl_pci_tx_chk_waitq()'.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602065940.149198-2-dmantipov@yandex.ru
Drop unused 'dualmac_easyconcurrent_retrytimer' of 'struct rtl_works',
corresponding 'rtl_easy_concurrent_retrytimer_callback()' handler,
'dualmac_easy_concurrent' function pointer of 'struct rtl_hal_ops'
and related call to 'timer_setup()' in '_rtl_init_deferred_work()'.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602065940.149198-1-dmantipov@yandex.ru
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: 063848c3e1 ("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
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: 16bbc3eb83 ("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
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.
Signed-off-by: Neal Sidhwaney <nealsid@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230603060021.57225-1-nealsid@gmail.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-8-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-7-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-6-pkshih@realtek.com
Configure the corresponding power type for 6 GHz regulatory if we can
determine one single target. Otherwise, we use the default one.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-5-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-4-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-3-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230602150556.36777-2-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230531060713.57203-5-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230531060713.57203-4-pkshih@realtek.com
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.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230531060713.57203-3-pkshih@realtek.com
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.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230531060713.57203-2-pkshih@realtek.com
Move the beacon loss work that might cause a disconnect
and the CSA disconnect work to be wiphy work, so we hold
the wiphy lock for them.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>
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>
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>
We'll need this later to convert other works that might
be cancelled from here, so convert this one first.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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>
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>
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>
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>
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>
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>
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>
This reverts commit b70813e4a8 ("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 1bcbb1208e ("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>
This should use wiphy_lock() now instead of requiring the
RTNL, since __cfg80211_leave() via cfg80211_leave() is now
requiring that lock to be held.
Fixes: a05829a722 ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This should use wiphy_lock() now instead of acquiring the
RTNL, since cfg80211_stop_sched_scan_req() now needs that.
Fixes: a05829a722 ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.3750c4ae6e76.I9e80d6026f59263c008a1a68f6cd6891ca0b93b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.48d262b6b42d.Ia15532657c17535c28ec0c5df263b65f0f80663c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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.
Fixes: cb71f1d136 ("wifi: mac80211: add sta link addition/removal")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.377adf3c789a.I91bf28f399e16e6ac1f83bacd1029a698b4e6685@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.d53b7018a4eb.I1adaa041de51d50d84a11226573e81ceac0fe90d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230504134511.828474-12-gregory.greenman@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We need to teach the low level driver about the EML capability which
includes information for EMLSR / EMLMR operation.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230504134511.828474-11-gregory.greenman@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Skip the EHT BSS membership selector for getting rates.
While at it, add the definitions for GLK and EPS, and
sort the list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230504134511.828474-9-gregory.greenman@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
