- New feature flag, NL80211_EXT_FEATURE_PUNCT, to advertise
driver support for preamble puncturing in AP mode.
- New attribute, NL80211_ATTR_PUNCT_BITMAP, to receive a puncturing
bitmap from the userspace during AP bring up (NL80211_CMD_START_AP)
and channel switch (NL80211_CMD_CHANNEL_SWITCH) operations. Each bit
corresponds to a 20 MHz channel in the operating bandwidth, lowest
bit for the lowest channel. Bit set to 1 indicates that the channel
is punctured. Higher 16 bits are reserved.
- New members added to structures cfg80211_ap_settings and
cfg80211_csa_settings to propagate the bitmap to the driver after
validation.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Muna Sinada <quic_msinada@quicinc.com>
Link: https://lore.kernel.org/r/20230131001227.25014-3-quic_alokad@quicinc.com
[move validation against 0xffff into policy]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
- Move ieee80211_valid_disable_subchannel_bitmap() from mlme.c to
chan.c, rename it as cfg80211_valid_disable_subchannel_bitmap()
and export it.
- Modify the prototype to include struct cfg80211_chan_def instead
of only bandwidth to support a check which returns false if the
primary channel is punctured.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://lore.kernel.org/r/20230131001227.25014-2-quic_alokad@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add an error message to the missing frequency case to have all
-EINVAL in nl80211_parse_chandef() return a better error.
Signed-off-by: Jaewan Kim <jaewan@google.com>
Link: https://lore.kernel.org/r/20230130074514.1560021-1-jaewan@google.com
[rewrite commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It is a frequent mistake to confuse the netlink port identifier with a
process identifier. Try to reduce this confusion by renaming
that hold port identifiers portid instead of pid.
This change replicates following commit:
commit 15e473046c ("netlink: Rename pid to portid to avoid confusion")
Signed-off-by: Jaewan Kim <jaewan@google.com>
Link: https://lore.kernel.org/r/20230130022252.1514647-1-jaewan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
nl80211_send_ap_stopped() can be called multiple times on the same
netdev for each link when using Multi-Link Operation. Add the
MLO_LINK_ID attribute to the event to allow userspace to distinguish
which link the event is for.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Link: https://lore.kernel.org/r/20230128125844.2407135-2-alvin@pqrs.dk
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Userspace processes such as network daemons may wish to be informed when
any AP interface is brought up on the system, for example to initiate a
(re)configuration of IP settings or to start a DHCP server.
Currently nl80211 does not broadcast any such event on its multicast
groups, leaving userspace only two options:
1. the process must be the one that actually issued the
NL80211_CMD_START_AP request, so that it can react on the response to
that request;
2. the process must react to RTM_NEWLINK events indicating a change in
carrier state, and may query for further information about the AP and
react accordingly.
Option (1) is robust, but it does not cover all scenarios. It is easy to
imagine a situation where this is not the case (e.g. hostapd +
systemd-networkd).
Option (2) is not robust, because RTM_NEWLINK events may be silently
discarded by the linkwatch logic (cf. linkwatch_fire_event()).
Concretely, consider a scenario in which the carrier state flip-flops in
the following way:
^ carrier state (high/low = carrier/no carrier)
|
| _______ _______ ...
| | | |
| ______| "foo" |____| "bar" (SSID in "quotes")
|
+-------A-------B----C---------> time
If the time interval between (A) and (C) is less than 1 second, then
linkwatch may emit only a single RTM_NEWLINK event indicating carrier
gain.
This is problematic because it is possible that the network
configuration that should be applied is a function of the AP's
properties such as SSID (cf. SSID= in systemd.network(5)). As
illustrated in the above diagram, it may be that the AP with SSID "bar"
ends up being configured as though it had SSID "foo".
Address the above issue by having nl80211 emit an NL80211_CMD_START_AP
message on the MLME nl80211 multicast group. This allows for arbitrary
processes to be reliably informed.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Link: https://lore.kernel.org/r/20230128125844.2407135-1-alvin@pqrs.dk
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Handle the Puncturing info received from the AP in the
EHT Operation element in beacons.
If the info is invalid:
- during association: disable EHT connection for the AP
- after association: disconnect
This commit includes many (internal) bugfixes and spec
updates various people.
Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://lore.kernel.org/r/20230127123930.4fbc74582331.I3547481d49f958389f59dfeba3fcc75e72b0aa6e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support to offload OWE processing to user space for MLD AP when
driver's SME in use.
Add new parameters in struct cfg80211_update_owe_info to provide below
information in cfg80211_update_owe_info_event() call:
- MLO link ID of the AP, with which station requested (re)association.
This is applicable for both MLO and non-MLO station connections when
the AP affiliated with an MLD.
- Station's MLD address if the connection is MLO capable.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20230126143256.960563-3-quic_vjakkam@quicinc.com
[reformat the trace event macro]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for drivers to indicate STA connection(MLO/non-MLO) when
user space SME (e.g., hostapd) is not used for MLD AP.
Add new parameters in struct station_info to provide below information
in cfg80211_new_sta() call:
- MLO link ID of the AP, with which station completed (re)association.
This is applicable for both MLO and non-MLO station connections when
the AP affiliated with an MLD.
- Station's MLD address if the connection is MLO capable.
- (Re)Association Response IEs sent to the station. User space needs
this to determine rejected and accepted affiliated links information
of the connected station if the connection is MLO capable.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20230126143256.960563-2-quic_vjakkam@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move color collision report in a dedicated delayed work and do not run
it in interrupt context in order to rate-limit the number of events
reported to userspace. Moreover grab wdev mutex in
ieee80211_color_collision_detection_work routine since it is required
by cfg80211_obss_color_collision_notify().
Tested-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Fixes: 5f9404abdf ("mac80211: add support for BSS color change")
Link: https://lore.kernel.org/r/3f6cf60c892ad40c1cca4a55d62b1224ef1c6ce9.1674644379.git.lorenzo@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Key information in wext.connect is not reset on (re)connect and can hold
data from a previous connection.
Reset key data to avoid that drivers or mac80211 incorrectly detect a
WEP connection request and access the freed or already reused memory.
Additionally optimize cfg80211_sme_connect() and avoid an useless
schedule of conn_work.
Fixes: fffd0934b9 ("cfg80211: rework key operation")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230124141856.356646-1-alexander@wetzel-home.de
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently authentication request event interface doesn't have support to
indicate the user space whether it should enable MLO or not during the
authentication with the specified AP. But driver needs such capability
since the connection is MLO or not decided by the driver in case of SME
offload to the driver.
Add support for driver to indicate MLD address of the AP in
authentication offload request to inform user space to enable MLO during
authentication process. Driver shall look at NL80211_ATTR_MLO_SUPPORT
flag capability in NL80211_CMD_CONNECT to know whether the user space
supports enabling MLO during the authentication offload.
User space should enable MLO during the authentication only when it
receives the AP MLD address in authentication offload request. User
space shouldn't enable MLO if the authentication offload request doesn't
indicate the AP MLD address even if the AP is MLO capable.
When MLO is enabled, user space should use the MAC address of the
interface (on which driver sent request) as self MLD address. User space
and driver to use MLD addresses in RA, TA and BSSID fields of the frames
between them, and driver translates the MLD addresses to/from link
addresses based on the link chosen for the authentication.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20230116125058.1604843-1-quic_vjakkam@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ath.git patches for v6.3. Major changes:
ath12k
* new driver for Qualcomm Wi-Fi 7 devices
ath11k
* IPQ5018 support
* Fine Timing Measurement (FTM) responder role support
* channel 177 support
ath10k
* store WLAN firmware version in SMEM image table
building with W=2 has these errors
redundant redeclaration of ‘zd_rf_generic_patch_6m’ [-Werror=redundant-decls]
redundant redeclaration of ‘zd_rf_patch_6m_band_edge’ [-Werror=redundant-decls]
Remove the second decls.
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230204200902.1709343-1-trix@redhat.com
Type of txdw7 is __le16, so assign __le32 is wrong. Also, the
TXDESC_ANTENNA_SELECT_C is defined for __le32, so shift 16 bits to fit
the value. Compile test only.
sparse warnings: (new ones prefixed by >>)
>> rtl8xxxu_core.c:5198:24: sparse: sparse: invalid assignment: |=
>> rtl8xxxu_core.c:5198:24: sparse: left side has type restricted __le16
>> rtl8xxxu_core.c:5198:24: sparse: right side has type restricted __le32
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230119113146.9640-1-pkshih@realtek.com
By default the LED will blink when there is some activity.
This is only compile tested.
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/73323811-aa58-a1be-7867-a5d45b7ae3d6@gmail.com
By default the LED will blink when there is some activity.
This was tested with a cheap "HT-WR813" from Aliexpress.
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/8f7fd5d7-5baa-b38b-ad2a-977dcd9edd81@gmail.com
By default the LED will blink when there is some activity.
This was tested with a TP-Link TL-WN725N.
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/34d62bf5-3595-0c77-2ca7-be78555f765d@gmail.com
If the chip can have an LED, register a struct led_classdev and enable
hardware-controlled blinking. When the chip is not transmitting or
receiving anything the LED is off. Otherwise the LED will blink
faster or slower according to the throughput.
The LED can be controlled from userspace by writing 0, 1, or 2 to
/sys/class/leds/rtl8xxxu-usbX-Y/brightness:
0 - solid off.
1 - solid on.
2 - hardware-controlled blinking.
In this patch none of the chips advertise having an LED. That will be
added in the next patches.
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/b8235bca-60c3-d0fe-a958-53c6dd3ba3f6@gmail.com
Macros prefixed with CONFIG_ are intended to be defined only by
Kconfig scripts. Here we remove the prefix from the
CONFIG_AUTO_READ_MODE define to avoid confusion when reading the code.
This causes no change to functionality.
Signed-off-by: Peter Lafreniere <peter@n8pjl.ca>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230118185353.2422-1-peter@n8pjl.ca
Previously, all supported chips had two RF paths. Therefore, these
codes used static number for TX power setting. Now, we are planning
to support a new chip which has only one RF path. So, we refine the
setting codes to refer to chip's RF path number at runtime.
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/20230203065157.8227-1-pkshih@realtek.com
For a packet with 1SS rate, it can also transmit via 2 antenna, called
2T mode. For 2T TX power offset, mask should be 2T as well. Fortunately,
the mask of 2T and 1T are the same, so it can still work well without
this fix.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230203064907.8046-1-pkshih@realtek.com
In path of setting channel and setting TX power, the rtw89_chan instance
to be used is controlled by top and passed down. The set_tx_shape_dfir()
is in path of setting TX power, so it should use the passed rtw89_chan
instead of querying it itself. Otherwise, it might encounter mismatch
between parameters if multi-channel.
For example,
rtw89_8852ce 0000:04:00.0: set tx shape dfir by unknown ch: 155 on 2GHz
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/20230201032057.7349-1-pkshih@realtek.com
Enable CLKREQ to reduce power consumption for 8852BE.
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/20230126112715.5811-1-pkshih@realtek.com
New firmware type NORMAL_CE is introduced to support P2P-PS and hardware
scan, but no LPS-PG mode. After this patch, old firmware with NORMAL type
can still work well.
The use of this new type is the same as before, so we add new type to
avoid taking wrong firmware. Then, driver log can also give clear
information about this change:
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-7-pkshih@realtek.com
Due to firmware size limit of 8852b, LPS-PG mode isn't supported after
0.29.26.0, and then we have more space to support other features, such as
P2P-PS, hardware scan and so on.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-6-pkshih@realtek.com
For different firmware type, it could use different IDMEM mode, so reset
it to default to avoid encountering error during we bisect firmware
version, like
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 5
rtw89_8852be 0000:03:00.0: Firmware version 0.29.26.0, cmd version 0, type 3
rtw89_8852be 0000:03:00.0: fw security fail
rtw89_8852be 0000:03:00.0: download firmware fail
rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x1E0 = 0x62
rtw89_8852be 0000:03:00.0: [ERR]fwdl 0x83F2 = 0x8
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931150
rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb8931154
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-5-pkshih@realtek.com
Driver can prepare pkt_list for firmware that only uses them to send out
the packets in specific situations. To understand the usage of current
status, and to check if there is leakage problem, dump bitmap and the
indices used by certain function.
An example looks like:
map:
...
pkt_ofld: 3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...
[SCAN 0]: 3
[SCAN 1]: 4
[SCAN 3]: 5
VIF [0] xx:xx:xx:xx:xx:xx
...
pkt_ofld[GENERAL]: 0 1 2
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123065401.14174-4-pkshih@realtek.com
For upcoming firmware, driver needs to do packet offload to firmware to
ensure LPS protocol work properly, so we update current connection and
disconnect flow to maintain packet offload flow, and integrate with
current WoWLAN flow which also needs packet offload.
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/20230123065401.14174-3-pkshih@realtek.com
When driver fails to send H2C to firmware for pkt-offload, we should not
update the pkt_list of driver, and need to release allocated pkt index to
avoid wrong mapping between driver and firmware.
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/20230123065401.14174-2-pkshih@realtek.com
Buffer STA on TDLS links are not currently supported. Therefore, it
is not allowed to enter the PS mode after TDLS link is established.
Signed-off-by: Kuan-Chung Chen <damon.chen@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/20230119064631.66971-1-pkshih@realtek.com
To debug channel concurrency more centrally, we add a new debug flag,
RTW89_DBG_CHAN, for channel related things, especially channel concurrency.
Then, we change MCC (multi-channel concurrency) C2H (chip to host packets)
debug flag to it.
Besides, refine debug logs to show TSF in u64 directly.
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/20230119064342.65391-2-pkshih@realtek.com
A 8-byte offset is missed during parsing C2Hs (chip to host packets)
of MCC (multi-channel concurrent) series.
So, we fix it.
Fixes: ef9dff4cb4 ("wifi: rtw89: mac: process MCC related C2H")
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/20230119064342.65391-1-pkshih@realtek.com
RXI300 is a HW design to maintain stuffs across BUS, e.g. AXI, AHB, APB.
It will feedback an error when host does an invalid BUS operation.
For example,
* BUS master request without power/clock on.
* host reads/writes/accesses an invalid address.
They might lead to problems such as BUS timeout, platform hang, etc. So,
once if RXI300 feedback an error, it notifies that driver need a L2 SER
(system error recovery) to reset things.
Previously, driver did not parse the error scenario for RXI300. We add
it and assign a corresponding error code which will make SER flow do L2
reset.
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/20230119063529.61563-3-pkshih@realtek.com
Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips,
this section is an address hole. It will lead to crash if trying to access
this section on chips except for 8852C. So, we avoid that.
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/20230119063529.61563-2-pkshih@realtek.com
Add mac function rtw89_mac_port_get_tsf() to get TSF by port.
It will be used when MCC (multi-channel concurrency) calculates
timing things.
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/20230119062453.58341-4-pkshih@realtek.com
Originally, rtw89_mac_port_tsf_sync() contains randomization logic
internally. However, not all situation, we need the randomization.
So, split out the generic part from it. And, make the full logic of
original one contained in rtw89_mac_port_tsf_sync_rand(). It will
still be used by its original caller as before. Then, the generic
one will be used in MCC (multi-channel concurrency) management flow.
MCC will implement its logic to decide the offset for TSF sync.
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/20230119062453.58341-3-pkshih@realtek.com
Strictly speaking, the unit of the offset should be TU instead of ms.
So, correct it and the macro for calculation. Then, to make the macro
generic, the factor n is moved outside.
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/20230119062453.58341-2-pkshih@realtek.com
Should update the driver with the supported firmware version of the
below item.
Bluetooth firmware BT_Coex_Ver: 0x07
Wi-Fi firmware version: RTL8852C->v0.27.56.10, RTL8852A->v0.24.36
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-9-pkshih@realtek.com
The origin code will enable TDMA WL:BT = 50:50 to prevent Wi-Fi
throughput suddenly drop to 0 in the moment while A2DP pause.
And this protection just a short moment, and will turn to Bluetooth
idle case when A2DP turn into sniff mode. But the raspberryPI simulated
A2DP device will not turn into sniff mode. So the protection will bring
the throughput drop.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-8-pkshih@realtek.com
When Wi-Fi enter and leave LPS, coexistence driver need to know
is there A2DP exist or not. And when Wi-Fi sleep in deep power save
state will not able to receive mailbox sent from Bluetooth. So update
the A2DP exist information from reading register.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-7-pkshih@realtek.com
When Wi-Fi is RX, set Bluetooth background scan to low-priority and
not to break Wi-Fi packet. Bluetooth can RX depend on hardware ability
even RX request has been rejected. This way can improve Wi-Fi RX
throughput performance.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-6-pkshih@realtek.com
Adjust the log format and correct variable reference to make the log
more readable.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-5-pkshih@realtek.com
Force firmware to update TDMA parameter when enter/exit power saving.
The TDMA instant feature will make firmware force update TDMA parameter
immediately when the TDMA parameter H2C to firmware. Without this feature,
it will have a low fail rate trigger Bluetooth audio sound glitch when
Wi-Fi is under power saving. Or Wi-Fi fail to turn in to power save state.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-4-pkshih@realtek.com
Reset the counter no matter Wi-Fi is notified turning into power save or
not. With rest the counter coexistence will recognize Bluetooth is hanged
easily.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-3-pkshih@realtek.com
This patch update the external control (Wi-Fi firmware control) type of
TDMA related parameters, almost all of these case were related to Wi-Fi
multi-role situations & AP mode.
Signed-off-by: Ching-Te Ku <ku920601@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/20230117114109.4298-2-pkshih@realtek.com
The function cfg80211_set_channel() is an static function in brcmfmac
but the name is misleading. Hence rename it with 'brcmf' prefix. Also
changing the parameters to avoid additional conversions.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230103124117.271988-4-arend.vanspriel@broadcom.com
This code re-uses "i" to be the iterator for both the inside and outside
loops. It means the outside loop will exit earlier than intended.
Fixes: d219b7eb37 ("mwifiex: handle BT coex event to adjust Rx BA window size")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/Y+ERnaDaZD7RtLvX@kili
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct mwifiex_ie_types_rates_param_set.
These are the only binary differences I see after the change:
mwifiex.o
_@@ -50154,7 +50154,7 @@
23514: R_X86_64_32S kmalloc_caches+0x50
23518: call 2351d <mwifiex_scan_networks+0x11d>
23519: R_X86_64_PLT32 __tsan_read8-0x4
- 2351d: mov $0x225,%edx
+ 2351d: mov $0x224,%edx
23522: mov $0xdc0,%esi
23527: mov 0x0(%rip),%rdi # 2352e <mwifiex_scan_networks+0x12e>
2352a: R_X86_64_PC32 kmalloc_caches+0x4c
scan.o
_@@ -5582,7 +5582,7 @@
4394: R_X86_64_32S kmalloc_caches+0x50
4398: call 439d <mwifiex_scan_networks+0x11d>
4399: R_X86_64_PLT32 __tsan_read8-0x4
- 439d: mov $0x225,%edx
+ 439d: mov $0x224,%edx
43a2: mov $0xdc0,%esi
43a7: mov 0x0(%rip),%rdi # 43ae <mwifiex_scan_networks+0x12e>
43aa: R_X86_64_PC32 kmalloc_caches+0x4c
and the reason for that is the following line:
drivers/net/wireless/marvell/mwifiex/scan.c:
1517 scan_cfg_out = kzalloc(sizeof(union mwifiex_scan_cmd_config_tlv),
1518 GFP_KERNEL);
sizeof(union mwifiex_scan_cmd_config_tlv) is now one-byte smaller due to the
flex-array transformation:
46 union mwifiex_scan_cmd_config_tlv {
47 /* Scan configuration (variable length) */
48 struct mwifiex_scan_cmd_config config;
49 /* Max allocated block */
50 u8 config_alloc_buf[MAX_SCAN_CFG_ALLOC];
51 };
Notice that MAX_SCAN_CFG_ALLOC is defined in terms of
sizeof(struct mwifiex_ie_types_rates_param_set), see:
26 /* Memory needed to store supported rate */
27 #define RATE_TLV_MAX_SIZE (sizeof(struct mwifiex_ie_types_rates_param_set) \
28 + HOSTCMD_SUPPORTED_RATES)
37 /* Maximum memory needed for a mwifiex_scan_cmd_config with all TLVs at max */
38 #define MAX_SCAN_CFG_ALLOC (sizeof(struct mwifiex_scan_cmd_config) \
39 + sizeof(struct mwifiex_ie_types_num_probes) \
40 + sizeof(struct mwifiex_ie_types_htcap) \
41 + CHAN_TLV_MAX_SIZE \
42 + RATE_TLV_MAX_SIZE \
43 + WILDCARD_SSID_TLV_MAX_SIZE)
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/252
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/Y9xkjXeElSEQ0FPY@work
