mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-05-14 04:09:18 -04:00
Code Issues Packages Projects Releases Wiki Activity
1,157,684 Commits 1 Branch 930 Tags
e820373a4fd06ebb6ed0331e97693048cfd16652
Commit Graph

1157684 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Johannes Berg
e820373a4f wifi: mac80211: fix ieee80211_link_set_associated() type 
The return type here should be u64 for the flags, even
if it doesn't matter right now because it doesn't return
any flags that don't fit into u32.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.d67ccae57d60.Ia4768e547ba8b1deb2b84ce3bbfbe216d5bfff6a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:57:11 +01:00
Johannes Berg
e8edb34640 wifi: mac80211: simplify reasoning about EHT capa handling 
Given the code in cfg80211, EHT capa cannot be non-NULL when
HE capa is NULL, but it's easier to reason about it if both
are checked and the compiler will likely integrate the check
with the previous one for HE capa anyway.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.7413d50d23bc.I6fef7484721be9bd5364f64921fc5e9168495f62@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:57:01 +01:00
Johannes Berg
15f9b3ef51 wifi: mac80211: mlme: remove pointless sta check 
We already exited the function if sta ended up NULL,
so just remove the extra check.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.4cbac9cfd03a.I21ec81c96d246afdabc2b0807d3856e6b1182cb7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:56:47 +01:00
Ilan Peer
5cf10940a4 wifi: mac80211_hwsim: Indicate support for NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT 
mac80211_hwsim always uses the probe request coming from mac80211,
which has support for minimal probe request content.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.67d31166ffd1.I908b68c5127525da3388c0d61a3d5d221ba451f6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:56:21 +01:00
Benjamin Berg
170cd6a66d wifi: mac80211: add netdev per-link debugfs data and driver hook 
This adds the infrastructure to have netdev specific per-link data both
for mac80211 and the driver in debugfs. For the driver, a new callback
is added which is only used if MLO is supported.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.fb4c947e4df8.I69b3516ddf4c8a7501b395f652d6063444ecad63@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:56:06 +01:00
Benjamin Berg
586100ad85 wifi: mac80211: remove SMPS from AP debugfs 
The spatial multiplexing power save feature does not apply to
AP mode. Remove it from debugfs in this case.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.01b167027dd5.Iee69f2e4df98581f259ef2c76309b940b20174be@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:55:56 +01:00
Benjamin Berg
e1f113cc67 wifi: mac80211: add pointer from bss_conf to vif 
While often not needed, this considerably simplifies going from a link
specific bss_config to the vif. This helps with e.g. creating link
specific debugfs entries inside drivers.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.46f701a10ed5.I20390b2a8165ff222d66585915689206ea93222b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:55:42 +01:00
Johannes Berg
a1e91ef923 wifi: mac80211: warn only once on AP probe 
We should perhaps support this API for MLO, but it's not
clear that it makes sense, in any case then we'd have to
update it to probe the correct BSS.

For now, if it happens, warn only once so that we don't
get flooded with messages if the driver misbehaves and
calls this.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.1c8499b6fbe6.I1a76a2be3b42ff93904870ac069f0319507adc23@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:55:25 +01:00
Johannes Berg
4c532321bf wifi: cfg80211/mac80211: report link ID on control port RX 
For control port RX, report the link ID for MLO.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.fe06dfc3791b.Iddcab94789cafe336417be406072ce8a6312fc2d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:55:06 +01:00
Avraham Stern
81202305f7 wifi: mac80211: add support for set_hw_timestamp command 
Support the set_hw_timestamp callback for enabling and disabling HW
timestamping if the low level driver supports it.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.700ded7badde.Ib2f7c228256ce313a04d3d9f9ecc6c7b9aa602bb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:54:48 +01:00
Avraham Stern
cbbaf2bb82 wifi: nl80211: add a command to enable/disable HW timestamping 
Add a command to enable and disable HW timestamping of TM and FTM
frames. HW timestamping can be enabled for a specific mac address
or for all addresses.

The low level driver will indicate how many peers HW timestamping
can be enabled concurrently, and this information will be passed
to userspace.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.05678d7b1c17.Iccc08869ea8156f1c71a3111a47f86dd56234bd0@changeid
[switch to needing netdev UP, minor edits]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:52:00 +01:00
Mordechay Goodstein
6ff9efcfc2 wifi: wireless: cleanup unused function parameters 
In the past ftype was used for deciding about 6G DUP beacon, but the
logic was removed and ftype is not needed anymore.

Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.98d4761b809b.I255f5ecd77cb24fcf2f1641bb5833ea2d121296e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:47:28 +01:00
Mordechay Goodstein
fb4b441c5d wifi: wireless: correct primary channel validation on 6 GHz 
The check that beacon primary channel is in the range of 80 MHz
(abs < 80) is invalid for 320 MHz since duplicate beacon transmit
means that the AP transmits it on all the 20 MHz sub-channels:

  9.4.2.249 HE Operation element - ... AP transmits Beacon frames in
  non-HT duplicate PPDU with a TXVECTOR parameter CH_BANDWIDTH value
  that is up to the BSS bandwidth.

So in case of 320 MHz the DUP beacon can be in upper 160 for primary
channel in the lower 160 giving possibly an absolute range of over
80 MHz.

Also this check is redundant alltogether, if AP has a wrong primary
channel in the beacon it's a faulty AP, and we would fail in next
steps to connect.

While at it, fix the frequency comparison to no longer compare
between KHz and MHz, which was introduced by commit 7f599aeccb
("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel").

Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.314faf725255.I5e27251ac558297553b590d3917a7b6d1aae0e74@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:46:38 +01:00
Mordechay Goodstein
724a486cd2 wifi: wireless: return primary channel regardless of DUP 
Currently in case DUP bit is not set we don't return the primary
channel for 6 GHz Band, but the spec says that the DUP bit has
no effect on this field:

9.4.2.249 HE Operation element:
The Duplicate Beacon subfield is set to 1 if the AP transmits
Beacon frames in non-HT duplicate PPDU with a TXVECTOR parameter
CH_BANDWIDTH value that is up to the BSS bandwidth and is set to
0 otherwise.

So remove the condition for returning primary channel based on DUP.

Since the caller code already marks the signal as invalid in case
the indicated frequency is not the tuned frequency, there's no need
to additionally handle this case here since that's already true for
duplicated beacons on the non-primary channel(s).

Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.66d7f05f7d11.I5e0add054f72ede95611391b99804c61c40cc959@changeid
[clarify commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:32:44 +01:00
Johannes Berg
d1b9bb6520 wifi: mac80211: allow beacon protection HW offload 
In case of beacon protection, check if the key was offloaded
to the hardware and in that case set control.hw_key so that
the encryption function will see it and only do the needed
steps that aren't done in hardware.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.b2becd9a22fb.I6c0b9c50c6a481128ba912a11cb7afc92c4b6da7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:30:04 +01:00
Johannes Berg
3ffcc659dc wifi: mac80211: check key taint for beacon protection 
This will likely never happen, but for completeness check
the key taint flag before using a key for beacon protection.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.cf2c3fee6f1f.I2f19b3e04e31c99bed3c9dc71935bf513b2cd177@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:29:53 +01:00
Mordechay Goodstein
3a867c7eef wifi: mac80211: clear all bits that relate rtap fields on skb 
Since we remove radiotap from skb data, clear all RX_FLAG_X related
info that indicate info on the skb data.

Also we need to do it only once so remove the clear from cooked_monitor.

Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.74d3efe19eae.Ie17a35864d2e120f9858516a2e3d3047d83cf805@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:29:46 +01:00
Johannes Berg
0fd3af6173 wifi: mac80211: adjust scan cancel comment/check 
Instead of the comment about holding RTNL, which is now wrong,
add a proper lockdep assertion for the wiphy mutex.

Fixes: a05829a722 ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.84352e46f342.Id90fef8c581cebe19cb30274340cf43885d55c74@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:28:51 +01:00
Ilan Peer
d509c55cda wifi: nl80211: Update the documentation of NL80211_SCAN_FLAG_COLOCATED_6GHZ 
Add a detailed description of NL80211_SCAN_FLAG_COLOCATED_6GHZ
flag.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230301115906.487ab04feb39.I5129fd61841332474693046241586f057b134c3c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
 2023-03-07 10:28:41 +01:00
Jiapeng Chong
ff6f38eb92 wifi: rtlwifi: rtl8192se: Remove some unused variables 
Variables bcntime_cfg, bcn_cw and bcn_ifs are not effectively used, so
delete them.

drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1555:6: warning: variable 'bcntime_cfg' set but not used.

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4240
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230302023911.59278-1-jiapeng.chong@linux.alibaba.com
 2023-03-06 12:10:06 +02:00
Martin Blumenstingl
15c8e267df wifi: rtw88: mac: Return the original error from rtw_mac_power_switch() 
rtw_mac_power_switch() calls rtw_pwr_seq_parser() which can return
-EINVAL, -EBUSY or 0. Propagate the original error code instead of
unconditionally returning -EINVAL in case of an error.

Fixes: e3037485c6 ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230226221004.138331-3-martin.blumenstingl@googlemail.com
 2023-03-06 12:09:34 +02:00
Martin Blumenstingl
b7ed9fa2cb wifi: rtw88: mac: Return the original error from rtw_pwr_seq_parser() 
rtw_pwr_seq_parser() calls rtw_sub_pwr_seq_parser() which can either
return -EBUSY, -EINVAL or 0. Propagate the original error code instead
of unconditionally returning -EBUSY in case of an error.

Fixes: e3037485c6 ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230226221004.138331-2-martin.blumenstingl@googlemail.com
 2023-03-06 12:09:34 +02:00
Konrad Dybcio
e5c3da9abd wifi: brcmfmac: pcie: Add 4359C0 firmware definition 
Some phones from around 2016, as well as other random devices have
this chip called 43956 or 4359C0 or 43596A0, which is more or less
just a rev bump (v9) of the already-supported 4359. Add a corresponding
firmware definition to allow for choosing the correct blob.

Suggested-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230224-topic-brcm_tone-v1-1-333b0ac67934@linaro.org
 2023-03-06 12:09:03 +02:00
Chih-Kang Chang
5c48f9432d wifi: rtw89: fix SER L1 might stop entering LPS issue 
When SER L1 triggered, driver need to stop Rx and clear RTW89_FLAG_RUNNING
flag. If track_work check RTW89_FLAG_RUNNING simultaneously, it will check
failed and never queue track_work again, and LPS won't enter either.
Therefore, we cancel delayed work when enter SER L1, and queue delayed work
when leave SER L1.

Signed-off-by: Chih-Kang Chang <gary.chang@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/20230224082117.21241-1-pkshih@realtek.com
 2023-03-06 12:05:59 +02:00
Hector Martin
1d5003d05f wifi: brcmfmac: pcie: Add BCM4378B3 support 
BCM4378B3 is a new silicon revision of BCM4378 present on the Apple M2
13" MacBook Pro "kyushu". Its PCI revision number is 5.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092838.17869-1-marcan@marcan.st
 2023-02-27 17:12:52 +02:00
Hector Martin
5b3ee9987f wifi: brcmfmac: common: Add support for external calibration blobs 
The calibration blob for a chip is normally stored in SROM and loaded
internally by the firmware. However, Apple ARM64 platforms instead store
it as part of platform configuration data, and provide it via the Apple
Device Tree. We forward this into the Linux DT in the bootloader.

Add support for taking this blob from the DT and loading it into the
dongle. The loading mechanism is the same as used for the CLM and TxCap
blobs.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-10-marcan@marcan.st
 2023-02-27 16:59:36 +02:00
Hector Martin
75102b7543 wifi: brcmfmac: pcie: Load and provide TxCap blobs 
These blobs are named .txcap_blob, and exist alongside the existing
.clm_blob files. Use the existing firmware machinery to provide them to
the core.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-9-marcan@marcan.st
 2023-02-27 16:59:36 +02:00
Hector Martin
dd7e55401f wifi: brcmfmac: common: Add support for downloading TxCap blobs 
The TxCap blobs are additional data blobs used on Apple devices, and
are uploaded analogously to CLM blobs. Add core support for doing this.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-8-marcan@marcan.st
 2023-02-27 16:59:36 +02:00
Hector Martin
117ace4014 wifi: brcmfmac: pcie: Add IDs/properties for BCM4387 
This chip is present on Apple M1 Pro/Max (t600x) platforms:

* maldives   (apple,j314s): MacBook Pro (14-inch, M1 Pro, 2021)
* maldives   (apple,j314c): MacBook Pro (14-inch, M1 Max, 2021)
* madagascar (apple,j316s): MacBook Pro (16-inch, M1 Pro, 2021)
* madagascar (apple,j316c): MacBook Pro (16-inch, M1 Max, 2021)

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-7-marcan@marcan.st
 2023-02-27 16:59:35 +02:00
Hector Martin
89b89e5215 wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex 
Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.

OpenBSD has been doing it like this from the beginning, so this should
work on all chips.

Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-6-marcan@marcan.st
 2023-02-27 16:59:35 +02:00
Hector Martin
a96202acae wifi: brcmfmac: cfg80211: Add support for PMKID_V3 operations 
Add support for the new PMKID_V3 API, which allows performing PMKID
mutations individually, instead of requiring the driver to keep track of
the full list. This new API is required by at least BCM4387.

Note that PMKID_V2 is not implemented yet.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-5-marcan@marcan.st
 2023-02-27 16:59:35 +02:00
Hector Martin
d75ef1f81e wifi: brcmfmac: feature: Add support for setting feats based on WLC version 
The "wlc_ver" iovar returns information on the WLC and EPI versions.
This can be used to determine whether the PMKID_V2 and _V3 features are
supported.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-4-marcan@marcan.st
 2023-02-27 16:59:35 +02:00
Hector Martin
398ce273d6 wifi: brcmfmac: cfg80211: Add support for scan params v2 
This new API version is required for at least the BCM4387 firmware. Add
support for it, with a fallback to the v1 API.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-3-marcan@marcan.st
 2023-02-27 16:59:34 +02:00
Hector Martin
098e0b105c wifi: brcmfmac: chip: Handle 1024-unit sizes for TCM blocks 
BCM4387 has trailing odd-sized blocks as part of TCM which have
their size described as a multiple of 1024 instead of 8192. Handle this
so we can compute the TCM size properly.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-2-marcan@marcan.st
 2023-02-27 16:59:34 +02:00
Hector Martin
3c7c07ca7a wifi: brcmfmac: chip: Only disable D11 cores; handle an arbitrary number 
At least on BCM4387, the D11 cores are held in reset on cold startup and
firmware expects to release reset itself. Just assert reset here and let
firmware deassert it. Premature deassertion results in the firmware
failing to initialize properly some of the time, with strange AXI bus
errors.

Also, BCM4387 has 3 cores, up from 2. The logic for handling that is in
brcmf_chip_ai_resetcore(), but since we aren't using that any more, just
handle it here.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214092423.15175-1-marcan@marcan.st
 2023-02-27 16:59:34 +02:00
John Keeping
ec52d77d07 wifi: brcmfmac: support CQM RSSI notification with older firmware 
Using the BCM4339 firmware from linux-firmware (version "BCM4339/2 wl0:
Sep  5 2019 11:05:52 version 6.37.39.113 (r722271 CY)" from
cypress/cyfmac4339-sdio.bin) the RSSI respose is only 4 bytes, which
results in an error being logged.

It seems that older devices send only the RSSI field and neither SNR nor
noise is included.  Handle this by accepting a 4 byte message and
reading only the RSSI from it.

Fixes: 7dd56ea45a ("brcmfmac: add support for CQM RSSI notifications")
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230124104248.2917465-1-john@metanate.com
 2023-02-27 12:42:10 +02:00
Hector Martin
91918ce88d wifi: brcmfmac: pcie: Provide a buffer of random bytes to the device 
Newer Apple firmwares on chipsets without a hardware RNG require the
host to provide a buffer of 256 random bytes to the device on
initialization. This buffer is present immediately before NVRAM,
suffixed by a footer containing a magic number and the buffer length.

This won't affect chips/firmwares that do not use this feature, so do it
unconditionally for all Apple platforms (those with an Apple OTP).

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214080034.3828-3-marcan@marcan.st
 2023-02-27 12:41:05 +02:00
Hector Martin
0f485805d0 wifi: brcmfmac: acpi: Add support for fetching Apple ACPI properties 
On DT platforms, the module-instance and antenna-sku-info properties
are passed in the DT. On ACPI platforms, module-instance is passed via
the analogous Apple device property mechanism, while the antenna SKU
info is instead obtained via an ACPI method that grabs it from
non-volatile storage.

Add support for this, to allow proper firmware selection on Apple
platforms.

Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230214080034.3828-2-marcan@marcan.st
 2023-02-27 12:41:05 +02:00
Zong-Zhe Yang
0d1f7ff19d wifi: rtw89: refine FW feature judgement on packet drop 
The newer chips use the newer firmware branches, e.g. v027, v029.
And, those firmware branches are supposed to support packet drop
when they are just branched out.

The initial firmware branch used by each chip is as below.
* 8852A: v009
* 8852C: v027
* 8852B: v027

So, only 8852A may use firmware which doesn't support packet drop at
runtime. To save trivial positive listing in firmware feature table,
we change to reverse judgment.

Besides, rtw89_mac_ptk_drop_by_band_and_wait() missed to check firmware
feature before calling rtw89_fw_h2c_pkt_drop(). We also fix it.

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/20230220070202.29868-7-pkshih@realtek.com
 2023-02-22 14:32:13 +02:00
Ping-Ke Shih
357277e1af wifi: rtw89: 8852b: enable hw_scan support 
This enables hw_scan for 8852b after firmware version 0.29.29.0.

Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230220070202.29868-6-pkshih@realtek.com
 2023-02-22 14:32:13 +02:00
Po-Hao Huang
4f24d7aa57 wifi: rtw89: 8852b: add channel encoding for hw_scan 
To obtain correct packet frequency for hw_scan, 52b needs to decode
the channel index obtained from hardware. Change the driver related
set channel part as well to make driver/firmware compatible.

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/20230220070202.29868-5-pkshih@realtek.com
 2023-02-22 14:32:12 +02:00
Po-Hao Huang
bb9040b3ff wifi: rtw89: adjust channel encoding to common function 
Since the range of channel table is identical among ICs. Make channel
encode/decode function common and not IC dependent. So all ICs with
matching firmware that needs this kind of coding can use it directly.
This patch doesn't change logic at all.

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/20230220070202.29868-4-pkshih@realtek.com
 2023-02-22 14:32:12 +02:00
Zong-Zhe Yang
31c416e69d wifi: rtw89: fw: configure CRASH_TRIGGER feature for 8852B 
RTL8852B firmware supports CRASH_TRIGGER feature from v0.29.29.0.
After this is configured, debugfs fw_crash can support type 1 on
RTL8852B 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/20230220070202.29868-3-pkshih@realtek.com
 2023-02-22 14:32:12 +02:00
Chin-Yen Lee
aa4e055945 wifi: rtw89: add tx_wake notify for 8852B 
8852B has the same issue: management frames get stuck when wifi
chip enters low ps mode, so we alse add notify wake function to
trigger wifi chip wake before forwarding management frames.

Signed-off-by: Chin-Yen Lee <timlee@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/20230220070202.29868-2-pkshih@realtek.com
 2023-02-22 14:32:12 +02:00
Martin Blumenstingl
ad0a677bce wifi: rtw88: rtw8822c: Implement RTL8822CS (SDIO) efuse parsing 
The efuse of the SDIO RTL8822CS chip has only one known member: the mac
address is at offset 0x16a. Add a struct rtw8822cs_efuse describing this
and use it for copying the mac address when the SDIO bus is used.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230218152944.48842-6-martin.blumenstingl@googlemail.com
 2023-02-22 14:31:37 +02:00
Martin Blumenstingl
9e688784b8 wifi: rtw88: rtw8822b: Implement RTL8822BS (SDIO) efuse parsing 
The efuse of the SDIO RTL8822BS chip has only one known member: the mac
address is at offset 0x11a. Add a struct rtw8822bs_efuse describing this
and use it for copying the mac address when the SDIO bus is used.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230218152944.48842-5-martin.blumenstingl@googlemail.com
 2023-02-22 14:31:37 +02:00
Martin Blumenstingl
64e9d56465 wifi: rtw88: rtw8821c: Implement RTL8821CS (SDIO) efuse parsing 
The efuse of the SDIO RTL8821CS chip has only one known member: the mac
address is at offset 0x11a. Add a struct rtw8821cs_efuse describing this
and use it for copying the mac address when the SDIO bus is used.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230218152944.48842-4-martin.blumenstingl@googlemail.com
 2023-02-22 14:31:37 +02:00
Martin Blumenstingl
8599ea4058 wifi: rtw88: mac: Add SDIO HCI support in the TX/page table setup 
txdma_queue_mapping() and priority_queue_cfg() can use the first entry
of each chip's rqpn_table and page_table. Add this mapping so data
transmission is possible on SDIO based chipsets.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230218152944.48842-3-martin.blumenstingl@googlemail.com
 2023-02-22 14:31:36 +02:00
Martin Blumenstingl
96c79da2e4 wifi: rtw88: mac: Add support for the SDIO HCI in rtw_pwr_seq_parser() 
rtw_pwr_seq_parser() needs to know about the HCI bus interface mask for
the SDIO bus so it can parse the chip state change sequences.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230218152944.48842-2-martin.blumenstingl@googlemail.com
 2023-02-22 14:31:36 +02:00
Bitterblue Smith
b9b1e4fe29 wifi: rtl8xxxu: Remove always true condition in rtl8xxxu_print_chipinfo 
Fix a new smatch warning:
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:1580 rtl8xxxu_print_chipinfo() warn: always true condition '(priv->chip_cut <= 15) => (0-15 <= 15)'

Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202302140753.71IgU77A-lkp@intel.com/
Fixes: 7b0ac469e3 ("wifi: rtl8xxxu: Recognise all possible chip cuts")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/68eff98b-a022-5a00-f330-adf623a35772@gmail.com
 2023-02-22 14:31:16 +02:00