OSDN Git Service
Sascha Hauer [Fri, 10 Feb 2023 11:16:32 +0000 (12:16 +0100)]
wifi: rtw88: usb: drop now unnecessary URB size check
Now that we send URBs with the URB_ZERO_PACKET flag set we no longer
need to make sure that the URB sizes are not multiple of the
bulkout_size. Drop the check.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230210111632.1985205-4-s.hauer@pengutronix.de
Sascha Hauer [Fri, 10 Feb 2023 11:16:31 +0000 (12:16 +0100)]
wifi: rtw88: usb: send Zero length packets if necessary
Zero length packets are necessary when sending URBs with size
multiple of bulkout_size, otherwise the hardware just stalls.
Fixes:
a82dfd33d1237 ("wifi: rtw88: Add common USB chip support")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230210111632.1985205-3-s.hauer@pengutronix.de
Sascha Hauer [Fri, 10 Feb 2023 11:16:30 +0000 (12:16 +0100)]
wifi: rtw88: usb: Set qsel correctly
We have to extract qsel from the skb before doing skb_push() on it,
otherwise qsel will always be 0.
Fixes:
a82dfd33d1237 ("wifi: rtw88: Add common USB chip support")
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230210111632.1985205-2-s.hauer@pengutronix.de
Johannes Berg [Tue, 14 Feb 2023 19:08:15 +0000 (20:08 +0100)]
wifi: mac80211: fix off-by-one link setting
The convention for find_first_bit() is 0-based, while ffs()
is 1-based, so this is now off-by-one. I cannot reproduce the
gcc-9 problem, but since the -1 is now removed, I'm hoping it
will still avoid the original issue.
Reported-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Fixes:
1d8d4af43474 ("wifi: mac80211: avoid u32_encode_bits() warning")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Gilad Itzkovitch [Thu, 24 Nov 2022 00:53:36 +0000 (13:53 +1300)]
wifi: mac80211: Fix for Rx fragmented action frames
The ieee80211_accept_frame() function performs a number of early checks
to decide whether or not further processing needs to be done on a frame.
One of those checks is the ieee80211_is_robust_mgmt_frame() function.
It requires to peek into the frame payload, but because defragmentation
does not occur until later on in the receive path, this peek is invalid
for any fragment other than the first one. Also, in this scenario there
is no STA and so the fragmented frame will be dropped later on in the
process and will not reach the upper stack. This can happen with large
action frames at low rates, for example, we see issues with DPP on S1G.
This change will only check if the frame is robust if it's the first
fragment. Invalid fragmented packets will be discarded later after
defragmentation is completed.
Signed-off-by: Gilad Itzkovitch <gilad.itzkovitch@morsemicro.com>
Link: https://lore.kernel.org/r/20221124005336.1618411-1-gilad.itzkovitch@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Arnd Bergmann [Tue, 14 Feb 2023 13:20:21 +0000 (14:20 +0100)]
wifi: mac80211: avoid u32_encode_bits() warning
gcc-9 triggers a false-postive warning in ieee80211_mlo_multicast_tx()
for u32_encode_bits(ffs(links) - 1, ...), since ffs() can return zero
on an empty bitmask, and the negative argument to u32_encode_bits()
is then out of range:
In file included from include/linux/ieee80211.h:21,
from include/net/cfg80211.h:23,
from net/mac80211/tx.c:23:
In function 'u32_encode_bits',
inlined from 'ieee80211_mlo_multicast_tx' at net/mac80211/tx.c:4437:17,
inlined from 'ieee80211_subif_start_xmit' at net/mac80211/tx.c:4485:3:
include/linux/bitfield.h:177:3: error: call to '__field_overflow' declared with attribute error: value doesn't fit into mask
177 | __field_overflow(); \
| ^~~~~~~~~~~~~~~~~~
include/linux/bitfield.h:197:2: note: in expansion of macro '____MAKE_OP'
197 | ____MAKE_OP(u##size,u##size,,)
| ^~~~~~~~~~~
include/linux/bitfield.h:200:1: note: in expansion of macro '__MAKE_OP'
200 | __MAKE_OP(32)
| ^~~~~~~~~
Newer compiler versions do not cause problems with the zero argument
because they do not consider this a __builtin_constant_p().
It's also harmless since the hweight16() check already guarantees
that this cannot be 0.
Replace the ffs() with an equivalent find_first_bit() check that
matches the later for_each_set_bit() style and avoids the warning.
Fixes:
963d0e8d08d9 ("wifi: mac80211: optionally implement MLO multicast TX")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230214132025.1532147-1-arnd@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Andrei Otcheretianski [Tue, 14 Feb 2023 10:10:48 +0000 (12:10 +0200)]
wifi: mac80211: Don't translate MLD addresses for multicast
MLD address translation should be done only for individually addressed
frames. Otherwise, AAD calculation would be wrong and the decryption
would fail.
Fixes:
e66b7920aa5ac ("wifi: mac80211: fix initialization of rx->link and rx->link_sta")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Link: https://lore.kernel.org/r/20230214101048.792414-1-andrei.otcheretianski@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Wen Gong [Wed, 1 Feb 2023 06:53:13 +0000 (01:53 -0500)]
wifi: cfg80211: call reg_notifier for self managed wiphy from driver hint
Currently the regulatory driver does not call the regulatory callback
reg_notifier for self managed wiphys. Sometimes driver needs cfg80211
to calculate the info of ieee80211_channel such as flags and power,
and driver needs to get the info of ieee80211_channel after hint of
driver, but driver does not know when calculation of the info of
ieee80211_channel become finished, so add notify to driver in
reg_process_self_managed_hint() from cfg80211 is a good way, then
driver could get the correct info in callback of reg_notifier.
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Link: https://lore.kernel.org/r/20230201065313.27203-1-quic_wgong@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Lorenzo Bianconi [Wed, 1 Feb 2023 12:48:30 +0000 (13:48 +0100)]
wifi: cfg80211: get rid of gfp in cfg80211_bss_color_notify
Since cfg80211_bss_color_notify() is now always run in non-atomic
context, get rid of gfp_t flags in the routine signature and always use
GFP_KERNEL for netlink message allocation.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/c687724e7b53556f7a2d9cbe3d11cdcf065cb687.1675255390.git.lorenzo@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Vinay Gannevaram [Sat, 4 Feb 2023 13:59:39 +0000 (19:29 +0530)]
wifi: nl80211: Allow authentication frames and set keys on NAN interface
Wi-Fi Aware R4 specification defines NAN Pairing which uses PASN handshake
to authenticate the peer and generate keys. Hence allow to register and transmit
the PASN authentication frames on NAN interface and set the keys to driver or
underlying modules on NAN interface.
The driver needs to configure the feature flag NL80211_EXT_FEATURE_SECURE_NAN,
which also helps userspace modules to know if the driver supports secure NAN.
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
Link: https://lore.kernel.org/r/1675519179-24174-1-git-send-email-quic_vganneva@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Karthikeyan Periyasamy [Mon, 6 Feb 2023 16:03:30 +0000 (21:33 +0530)]
wifi: mac80211: fix non-MLO station association
Non-MLO station frames are dropped in Rx path due to the condition
check in ieee80211_rx_is_valid_sta_link_id(). In multi-link AP scenario,
non-MLO stations try to connect in any of the valid links in the ML AP,
where the station valid_links and link_id params are valid in the
ieee80211_sta object. But ieee80211_rx_is_valid_sta_link_id() always
return false for the non-MLO stations by the assumption taken is
valid_links and link_id are not valid in non-MLO stations object
(ieee80211_sta), this assumption is wrong. Due to this assumption,
non-MLO station frames are dropped which leads to failure in association.
Fix it by removing the condition check and allow the link validation
check for the non-MLO stations.
Fixes:
e66b7920aa5a ("wifi: mac80211: fix initialization of rx->link and rx->link_sta")
Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com>
Link: https://lore.kernel.org/r/20230206160330.1613-1-quic_periyasa@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rameshkumar Sundaram [Tue, 7 Feb 2023 11:41:46 +0000 (17:11 +0530)]
wifi: mac80211: Allow NSS change only up to capability
Stations can update bandwidth/NSS change in
VHT action frame with action type Operating Mode Notification.
(IEEE Std 802.11-2020 - 9.4.1.53 Operating Mode field)
For Operating Mode Notification, an RX NSS change to a value
greater than AP's maximum NSS should not be allowed.
During fuzz testing, by forcefully sending VHT Op. mode notif.
frames from STA with random rx_nss values, it is found that AP
accepts rx_nss values greater that APs maximum NSS instead of
discarding such NSS change.
Hence allow NSS change only up to maximum NSS that is negotiated
and capped to AP's capability during association.
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Link: https://lore.kernel.org/r/20230207114146.10567-1-quic_ramess@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Felix Fietkau [Mon, 13 Feb 2023 10:08:55 +0000 (11:08 +0100)]
wifi: mac80211: add a workaround for receiving non-standard mesh A-MSDU
At least ath10k and ath11k supported hardware (maybe more) does not implement
mesh A-MSDU aggregation in a standard compliant way.
802.11-2020 9.3.2.2.2 declares that the Mesh Control field is part of the
A-MSDU header (and little-endian).
As such, its length must not be included in the subframe length field.
Hardware affected by this bug treats the mesh control field as part of the
MSDU data and sets the length accordingly.
In order to avoid packet loss, keep track of which stations are affected
by this and take it into account when converting A-MSDU to 802.3 + mesh control
packets.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230213100855.34315-5-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Felix Fietkau [Mon, 13 Feb 2023 10:08:54 +0000 (11:08 +0100)]
wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces
The current mac80211 mesh A-MSDU receive path fails to parse A-MSDU packets
on mesh interfaces, because it assumes that the Mesh Control field is always
directly after the 802.11 header.
802.11-2020 9.3.2.2.2 Figure 9-70 shows that the Mesh Control field is
actually part of the A-MSDU subframe header.
This makes more sense, since it allows packets for multiple different
destinations to be included in the same A-MSDU, as long as RA and TID are
still the same.
Another issue is the fact that the A-MSDU subframe length field was apparently
accidentally defined as little-endian in the standard.
In order to fix this, the mesh forwarding path needs happen at a different
point in the receive path.
ieee80211_data_to_8023_exthdr is changed to ignore the mesh control field
and leave it in after the ethernet header. This also affects the source/dest
MAC address fields, which now in the case of mesh point to the mesh SA/DA.
ieee80211_amsdu_to_8023s is changed to deal with the endian difference and
to add the Mesh Control length to the subframe length, since it's not covered
by the MSDU length field.
With these changes, the mac80211 will get the same packet structure for
converted regular data packets and unpacked A-MSDU subframes.
The mesh forwarding checks are now only performed after the A-MSDU decap.
For locally received packets, the Mesh Control header is stripped away.
For forwarded packets, a new 802.11 header gets added.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230213100855.34315-4-nbd@nbd.name
[fix fortify build error]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Felix Fietkau [Mon, 13 Feb 2023 10:08:53 +0000 (11:08 +0100)]
wifi: mac80211: remove mesh forwarding congestion check
Now that all drivers use iTXQ, it does not make sense to check to drop
tx forwarding packets when the driver has stopped the queues.
fq_codel will take care of dropping packets when the queues fill up
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230213100855.34315-3-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Felix Fietkau [Mon, 13 Feb 2023 10:08:52 +0000 (11:08 +0100)]
wifi: cfg80211: factor out bridge tunnel / RFC1042 header check
The same check is done in multiple places, unify it.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230213100855.34315-2-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Felix Fietkau [Mon, 13 Feb 2023 10:08:51 +0000 (11:08 +0100)]
wifi: cfg80211: move A-MSDU check in ieee80211_data_to_8023_exthdr
When parsing the outer A-MSDU header, don't check for inner bridge tunnel
or RFC1042 headers. This is handled by ieee80211_amsdu_to_8023s already.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230213100855.34315-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Shayne Chen [Thu, 9 Feb 2023 11:06:59 +0000 (19:06 +0800)]
wifi: mac80211: make rate u32 in sta_set_rate_info_rx()
The value of last_rate in ieee80211_sta_rx_stats is degraded from u32 to
u16 after being assigned to rate variable, which causes information loss
in STA_STATS_FIELD_TYPE and later bitfields.
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Link: https://lore.kernel.org/r/20230209110659.25447-1-shayne.chen@mediatek.com
Fixes:
41cbb0f5a295 ("mac80211: add support for HE")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bo Liu [Mon, 6 Feb 2023 08:16:41 +0000 (03:16 -0500)]
rfkill: Use sysfs_emit() to instead of sprintf()
Follow the advice of the Documentation/filesystems/sysfs.rst and show()
should only use sysfs_emit() or sysfs_emit_at() when formatting the
value to be returned to user space.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230206081641.3193-1-liubo03@inspur.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rameshkumar Sundaram [Wed, 1 Feb 2023 06:16:02 +0000 (11:46 +0530)]
wifi: cfg80211: Allow action frames to be transmitted with link BSS in MLD
Currently action frames TX only with ML address as A3(BSSID) are
allowed in an ML AP, but TX for a non-ML Station can happen in any
link of an ML BSS with link BSS address as A3.
In case of an MLD, if User-space has provided a valid link_id in
action frame TX request, allow transmission of the frame in that link.
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Link: https://lore.kernel.org/r/20230201061602.3918-1-quic_ramess@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Aloka Dixit [Tue, 31 Jan 2023 00:12:27 +0000 (16:12 -0800)]
wifi: mac80211: configure puncturing bitmap
- Configure the bitmap in link_conf and notify the driver.
- Modify 'change' in ieee80211_start_ap() from u32 to u64 to support
BSS_CHANGED_EHT_PUNCTURING.
- Propagate the bitmap in channel switch events to userspace.
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-5-quic_alokad@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Aloka Dixit [Tue, 31 Jan 2023 00:12:26 +0000 (16:12 -0800)]
wifi: cfg80211: include puncturing bitmap in channel switch events
Add puncturing bitmap in channel switch notifications
and corresponding trace functions.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://lore.kernel.org/r/20230131001227.25014-4-quic_alokad@quicinc.com
[fix qtnfmac]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Aloka Dixit [Tue, 31 Jan 2023 00:12:25 +0000 (16:12 -0800)]
wifi: nl80211: validate and configure puncturing bitmap
- 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>
Aloka Dixit [Tue, 31 Jan 2023 00:12:24 +0000 (16:12 -0800)]
wifi: cfg80211: move puncturing bitmap validation from mac80211
- 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>
Jaewan Kim [Mon, 30 Jan 2023 07:45:14 +0000 (07:45 +0000)]
wifi: nl80211: return error message for malformed chandef
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>
Jaewan Kim [Mon, 30 Jan 2023 02:22:52 +0000 (02:22 +0000)]
wifi: mac80211_hwsim: Rename pid to portid to avoid confusion
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
15e473046cb6 ("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>
Alvin Šipraga [Sat, 28 Jan 2023 12:58:44 +0000 (13:58 +0100)]
wifi: nl80211: add MLO_LINK_ID to CMD_STOP_AP event
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>
Alvin Šipraga [Sat, 28 Jan 2023 12:58:43 +0000 (13:58 +0100)]
wifi: nl80211: emit CMD_START_AP on multicast group when an AP is started
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>
Johannes Berg [Fri, 27 Jan 2023 11:39:31 +0000 (12:39 +0100)]
wifi: mac80211: mlme: handle EHT channel puncturing
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>
Veerendranath Jakkam [Thu, 26 Jan 2023 14:32:56 +0000 (20:02 +0530)]
wifi: cfg80211: Extend cfg80211_update_owe_info_event() for MLD AP
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>
Veerendranath Jakkam [Thu, 26 Jan 2023 14:32:55 +0000 (20:02 +0530)]
wifi: cfg80211: Extend cfg80211_new_sta() for MLD AP
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>
Lorenzo Bianconi [Wed, 25 Jan 2023 11:01:02 +0000 (12:01 +0100)]
wifi: mac80211: move color collision detection report in a delayed work
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:
5f9404abdf2a ("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>
Alexander Wetzel [Tue, 24 Jan 2023 14:18:56 +0000 (15:18 +0100)]
wifi: cfg80211: Fix use after free for wext
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:
fffd0934b939 ("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>
Veerendranath Jakkam [Mon, 16 Jan 2023 12:50:58 +0000 (18:20 +0530)]
wifi: cfg80211: Authentication offload to user space for MLO connection in STA mode
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>
Johannes Berg [Thu, 19 Jan 2023 13:45:47 +0000 (14:45 +0100)]
wifi: cfg80211: trace: remove MAC_PR_{FMT,ARG}
With %pM, this really is no longer needed, and actually
longer to spell out. Remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Kalle Valo [Mon, 13 Feb 2023 18:08:01 +0000 (20:08 +0200)]
Merge ath-next from git://git./linux/kernel/git/kvalo/ath.git
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
Tom Rix [Sat, 4 Feb 2023 20:09:02 +0000 (12:09 -0800)]
wifi: zd1211rw: remove redundant decls
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
Ping-Ke Shih [Thu, 19 Jan 2023 11:31:46 +0000 (19:31 +0800)]
wifi: rtl8xxxu: fix txdw7 assignment of TX DESC v3
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
Bitterblue Smith [Fri, 20 Jan 2023 15:55:09 +0000 (17:55 +0200)]
wifi: rtl8xxxu: Add LED control code for RTL8723AU
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
Bitterblue Smith [Fri, 20 Jan 2023 15:54:18 +0000 (17:54 +0200)]
wifi: rtl8xxxu: Add LED control code for RTL8192EU
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
Bitterblue Smith [Fri, 20 Jan 2023 15:52:40 +0000 (17:52 +0200)]
wifi: rtl8xxxu: Add LED control code for RTL8188EU
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
Bitterblue Smith [Fri, 20 Jan 2023 15:51:21 +0000 (17:51 +0200)]
wifi: rtl8xxxu: Register the LED and make it blink
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
Peter Lafreniere [Wed, 18 Jan 2023 18:53:53 +0000 (13:53 -0500)]
wifi: rsi: Avoid defines prefixed with CONFIG
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
Zong-Zhe Yang [Fri, 3 Feb 2023 06:51:57 +0000 (14:51 +0800)]
wifi: rtw89: phy: set TX power according to RF path number by chip
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
Ping-Ke Shih [Fri, 3 Feb 2023 06:49:07 +0000 (14:49 +0800)]
wifi: rtw89: 8852b: correct register mask name of TX power offset
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
Zong-Zhe Yang [Wed, 1 Feb 2023 03:20:57 +0000 (11:20 +0800)]
wifi: rtw89: use passed channel in set_tx_shape_dfir()
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
Chin-Yen Lee [Thu, 26 Jan 2023 11:27:15 +0000 (19:27 +0800)]
wifi: rtw89: 8852be: enable CLKREQ of PCI capability
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
Ping-Ke Shih [Mon, 23 Jan 2023 06:54:01 +0000 (14:54 +0800)]
wifi: rtw89: 8852b: try to use NORMAL_CE type firmware first
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
Ping-Ke Shih [Mon, 23 Jan 2023 06:54:00 +0000 (14:54 +0800)]
wifi: rtw89: 8852b: don't support LPS-PG mode after firmware 0.29.26.0
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
Ping-Ke Shih [Mon, 23 Jan 2023 06:53:59 +0000 (14:53 +0800)]
wifi: rtw89: 8852b: reset IDMEM mode to default value
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
Ping-Ke Shih [Mon, 23 Jan 2023 06:53:58 +0000 (14:53 +0800)]
wifi: rtw89: add use of pkt_list offload to debug entry
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
Chin-Yen Lee [Mon, 23 Jan 2023 06:53:57 +0000 (14:53 +0800)]
wifi: rtw89: refine packet offload flow
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
Chin-Yen Lee [Mon, 23 Jan 2023 06:53:56 +0000 (14:53 +0800)]
wifi: rtw89: fix potential wrong mapping for pkt-offload
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
Kuan-Chung Chen [Thu, 19 Jan 2023 06:46:31 +0000 (14:46 +0800)]
wifi: rtw89: disallow enter PS mode after create TDLS link
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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:43:42 +0000 (14:43 +0800)]
wifi: rtw89: refine MCC C2H debug logs
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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:43:41 +0000 (14:43 +0800)]
wifi: rtw89: fix parsing offset for MCC C2H
A 8-byte offset is missed during parsing C2Hs (chip to host packets)
of MCC (multi-channel concurrent) series.
So, we fix it.
Fixes:
ef9dff4cb491 ("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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:35:29 +0000 (14:35 +0800)]
wifi: rtw89: deal with RXI300 error
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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:35:28 +0000 (14:35 +0800)]
wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30
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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:24:53 +0000 (14:24 +0800)]
wifi: rtw89: mac: add function to get TSF
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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:24:52 +0000 (14:24 +0800)]
wifi: rtw89: split out generic part of rtw89_mac_port_tsf_sync()
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
Zong-Zhe Yang [Thu, 19 Jan 2023 06:24:51 +0000 (14:24 +0800)]
wifi: rtw89: correct unit for port offset and refine macro
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:09 +0000 (19:41 +0800)]
wifi: rtw89: coex: Update Wi-Fi Bluetooth coexistence version to 7.0.0
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:08 +0000 (19:41 +0800)]
wifi: rtw89: coex: Fix test fail when coexist with raspberryPI A2DP idle
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:07 +0000 (19:41 +0800)]
wifi: rtw89: coex: Correct A2DP exist variable source
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:06 +0000 (19:41 +0800)]
wifi: rtw89: coex: Set Bluetooth background scan PTA request priority
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:05 +0000 (19:41 +0800)]
wifi: rtw89: coex: Refine coexistence log
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:04 +0000 (19:41 +0800)]
wifi: rtw89: coex: Force to update TDMA parameter when radio state change
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:03 +0000 (19:41 +0800)]
wifi: rtw89: coex: Clear Bluetooth HW PTA counter when radio state change
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
Ching-Te Ku [Tue, 17 Jan 2023 11:41:02 +0000 (19:41 +0800)]
wifi: rtw89: coex: Update Wi-Fi external control TDMA parameters/tables
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
Arend van Spriel [Tue, 3 Jan 2023 12:41:17 +0000 (13:41 +0100)]
wifi: brcmfmac: change cfg80211_set_channel() name and signature
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
Dan Carpenter [Mon, 6 Feb 2023 14:41:33 +0000 (17:41 +0300)]
wifi: mwifiex: fix loop iterator in mwifiex_update_ampdu_txwinsize()
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:
d219b7eb3792 ("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
Gustavo A. R. Silva [Fri, 3 Feb 2023 01:34:05 +0000 (19:34 -0600)]
wifi: mwifiex: Replace one-element array with flexible-array member
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
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
Gustavo A. R. Silva [Fri, 3 Feb 2023 01:32:00 +0000 (19:32 -0600)]
wifi: mwifiex: Replace one-element arrays with flexible-array members
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element arrays with flexible-array
members in multiple structures.
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].
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/256
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html
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/Y9xkECG3uTZ6T1dN@work
Gustavo A. R. Silva [Fri, 3 Feb 2023 01:29:47 +0000 (19:29 -0600)]
wifi: brcmfmac: Replace one-element array with flexible-array member
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 brcmf_tlv.
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].
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/253
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html
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/Y9xjizhMujNEtpB4@work
Lukas Wunner [Fri, 27 Jan 2023 14:03:00 +0000 (15:03 +0100)]
wifi: mwifiex: Support firmware hotfix version in GET_HW_SPEC responses
Support the firmware hotfix version in GET_HW_SPEC responses to avoid an
irritating "Unknown api_id: 5" message on probe.
Based on this commit in NXP's GPLv2-licensed out-of-tree driver:
https://github.com/nxp-imx/mwifiex/commit/
27fd8ecca504
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/111c7ee895f12d951e95a2edcd06d87ca26a7d0f.1674827105.git.lukas@wunner.de
Lukas Wunner [Fri, 27 Jan 2023 14:02:00 +0000 (15:02 +0100)]
wifi: mwifiex: Support SD8978 chipset
The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987,
so reuse the existing mwifiex_reg_sd8987 definition.
Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise
identical, save for the fw_dump_ctrl register: They define it as 0xf0
whereas mwifiex_reg_sd8987 defines it as 0xf9. I've verified that
0xf9 is the correct value on SD8978. NXP's out-of-tree driver uses
0xf9 for all of them, so there's a chance that 0xf0 is not correct
in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions. I cannot
test that for lack of hardware, hence am leaving it as is.
NXP has only released a firmware which runs Bluetooth over UART.
Perhaps Bluetooth over SDIO is unsupported by this chipset.
Consequently, only an "sdiouart" firmware image is referenced, not an
alternative "sdsd" image.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/536b4f17a72ca460ad1b07045757043fb0778988.1674827105.git.lukas@wunner.de
Lukas Wunner [Fri, 27 Jan 2023 14:01:00 +0000 (15:01 +0100)]
wifi: mwifiex: Add missing compatible string for SD8787
Commit
e3fffc1f0b47 ("devicetree: document new marvell-8xxx and
pwrseq-sd8787 options") documented a compatible string for SD8787 in
the devicetree bindings, but neglected to add it to the mwifiex driver.
Fixes:
e3fffc1f0b47 ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options")
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v4.11+
Cc: Matt Ranostay <mranostay@ti.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/320de5005ff3b8fd76be2d2b859fd021689c3681.1674827105.git.lukas@wunner.de
Hector Martin [Sun, 12 Feb 2023 06:38:13 +0000 (15:38 +0900)]
wifi: brcmfmac: pcie: Perform correct BCM4364 firmware selection
This chip exists in two revisions (B2=r3 and B3=r4) on different
platforms, and was added without regard to doing proper firmware
selection or differentiating between them. Fix this to have proper
per-revision firmwares and support Apple NVRAM selection.
Revision B2 is present on at least these Apple T2 Macs:
kauai: MacBook Pro 15" (Touch/2018-2019)
maui: MacBook Pro 13" (Touch/2018-2019)
lanai: Mac mini (Late 2018)
ekans: iMac Pro 27" (5K, Late 2017)
And these non-T2 Macs:
nihau: iMac 27" (5K, 2019)
Revision B3 is present on at least these Apple T2 Macs:
bali: MacBook Pro 16" (2019)
trinidad: MacBook Pro 13" (2020, 4 TB3)
borneo: MacBook Pro 16" (2019, 5600M)
kahana: Mac Pro (2019)
kahana: Mac Pro (2019, Rack)
hanauma: iMac 27" (5K, 2020)
kure: iMac 27" (5K, 2020, 5700/XT)
Also fix the firmware interface for 4364, from BCA to WCC.
Fixes:
24f0bd136264 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
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/20230212063813.27622-5-marcan@marcan.st
Hector Martin [Sun, 12 Feb 2023 06:38:12 +0000 (15:38 +0900)]
wifi: brcmfmac: pcie: Add IDs/properties for BCM4377
This chip is present on at least these Apple T2 Macs:
* tahiti: MacBook Pro 13" (2020, 2 TB3)
* formosa: MacBook Pro 13" (Touch/2019)
* fiji: MacBook Air 13" (Scissor, 2020)
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/20230212063813.27622-4-marcan@marcan.st
Hector Martin [Sun, 12 Feb 2023 06:38:11 +0000 (15:38 +0900)]
wifi: brcmfmac: pcie: Add IDs/properties for BCM4355
This chip is present on at least these Apple T2 Macs:
* hawaii: MacBook Air 13" (Late 2018)
* hawaii: MacBook Air 13" (True Tone, 2019)
Users report seeing PCI revision ID 12 for this chip, which Arend
reports should be revision C2, but Apple has the firmware tagged as
revision C1. Assume the right cutoff point for firmware versions is
revision ID 11 then, and leave older revisions using the non-versioned
firmware filename (Apple only uses C1 firmware builds).
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/20230212063813.27622-3-marcan@marcan.st
Hector Martin [Sun, 12 Feb 2023 06:38:10 +0000 (15:38 +0900)]
wifi: brcmfmac: Rename Cypress 89459 to BCM4355
The commit that introduced support for this chip incorrectly claimed it
is a Cypress-specific part, while in actuality it is just a variant of
BCM4355 silicon (as evidenced by the chip ID).
The relationship between Cypress products and Broadcom products isn't
entirely clear but given what little information is available and prior
art in the driver, it seems the convention should be that originally
Broadcom parts should retain the Broadcom name.
Thus, rename the relevant constants and firmware file. Also rename the
specific 89459 PCIe ID to BCM43596, which seems to be the original
subvariant name for this PCI ID (as defined in the out-of-tree bcmdhd
driver).
Since Cypress added this part and will presumably be providing its
supported firmware, we keep the CYW designation for this device.
We also drop the RAW device ID in this commit. We don't do this for the
other chips since apparently some devices with them exist in the wild,
but there is already a 4355 entry with the Broadcom subvendor and WCC
firmware vendor, so adding a generic fallback to Cypress seems
redundant (no reason why a device would have the raw device ID *and* an
explicitly programmed subvendor).
Fixes:
dce45ded7619 ("brcmfmac: Support 89459 pcie")
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/20230212063813.27622-2-marcan@marcan.st
Krzysztof Kozlowski [Wed, 18 Jan 2023 17:54:13 +0000 (18:54 +0100)]
dt-bindings: net: wireless: minor whitespace and name cleanups
Minor cleanups:
- Drop redundant blank lines,
- Correct indentaion in examples,
- Correct node names in examples to drop underscore and use generic
name.
No functional impact except adjusting to preferred coding style.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230118175413.360153-1-krzysztof.kozlowski@linaro.org
Jiasheng Jiang [Thu, 9 Feb 2023 01:07:48 +0000 (09:07 +0800)]
wifi: iwl4965: Add missing check for create_singlethread_workqueue()
Add the check for the return value of the create_singlethread_workqueue()
in order to avoid NULL pointer dereference.
Fixes:
b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230209010748.45454-1-jiasheng@iscas.ac.cn
Jiasheng Jiang [Wed, 8 Feb 2023 06:30:32 +0000 (14:30 +0800)]
wifi: iwl3945: Add missing check for create_singlethread_workqueue
Add the check for the return value of the create_singlethread_workqueue
in order to avoid NULL pointer dereference.
Fixes:
b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230208063032.42763-2-jiasheng@iscas.ac.cn
Martin Blumenstingl [Sat, 4 Feb 2023 23:30:01 +0000 (00:30 +0100)]
wifi: rtw88: mac: Use existing macros in rtw_pwr_seq_parser()
Replace the magic numbers for the intf_mask with their existing
RTW_PWR_INTF_PCI_MSK and RTW_PWR_INTF_USB_MSK macros to make the code
easier to understand.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230204233001.1511643-5-martin.blumenstingl@googlemail.com
Martin Blumenstingl [Sat, 4 Feb 2023 23:30:00 +0000 (00:30 +0100)]
wifi: rtw88: Move enum rtw_tx_queue_type mapping code to tx.{c,h}
This code is not specific to the PCIe bus type but can be re-used by USB
and SDIO bus types. Move it to tx.{c,h} to avoid code-duplication in the
future. While here, add checking of the ac argument in
rtw_tx_ac_to_hwq() so we're not accessing entries beyond the end of the
array.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230204233001.1511643-4-martin.blumenstingl@googlemail.com
Martin Blumenstingl [Sat, 4 Feb 2023 23:29:59 +0000 (00:29 +0100)]
wifi: rtw88: pci: Change queue datatype to enum rtw_tx_queue_type
This makes it easier to understand which values are allowed for the
"queue" variable when using the enum instead of an u8.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230204233001.1511643-3-martin.blumenstingl@googlemail.com
Martin Blumenstingl [Sat, 4 Feb 2023 23:29:58 +0000 (00:29 +0100)]
wifi: rtw88: pci: Use enum type for rtw_hw_queue_mapping() and ac_to_hwq
rtw_hw_queue_mapping() and ac_to_hwq[] hold values of type enum
rtw_tx_queue_type. Change their types to reflect this to make it easier
to understand this part of the code.
While here, also change the array to be static const as it is not
supposed to be modified at runtime.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230204233001.1511643-2-martin.blumenstingl@googlemail.com
Jonathan Neuschäfer [Sun, 29 Jan 2023 12:49:18 +0000 (13:49 +0100)]
wifi: wl1251: Fix a typo ("boradcast")
It should be "broadcast".
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230129124919.1305057-1-j.neuschaefer@gmx.net
Doug Brown [Mon, 23 Jan 2023 05:31:32 +0000 (21:31 -0800)]
wifi: libertas: add support for WPS enrollee IE in probe requests
Add compatibility with WPS by passing on WPS enrollee information in
probe requests. Ignore other IEs supplied in the scan request. This also
has the added benefit of restoring compatibility with newer
wpa_supplicant versions that always add scan IEs. Previously, with
max_scan_ie_len set to 0, scans would always fail.
Suggested-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Doug Brown <doug@schmorgal.com>
Reviewed-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123053132.30710-5-doug@schmorgal.com
Doug Brown [Mon, 23 Jan 2023 05:31:31 +0000 (21:31 -0800)]
wifi: libertas: add new TLV type for WPS enrollee IE
Add a define for the TLV type that will be used to add WPS enrollee
information to probe requests.
Suggested-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Doug Brown <doug@schmorgal.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123053132.30710-4-doug@schmorgal.com
Doug Brown [Mon, 23 Jan 2023 05:31:30 +0000 (21:31 -0800)]
wifi: libertas: only add RSN/WPA IE in lbs_add_wpa_tlv
The existing code only converts the first IE to a TLV, but it returns a
value that takes the length of all IEs into account. When there is more
than one IE (which happens with modern wpa_supplicant versions for
example), the returned length is too long and extra junk TLVs get sent
to the firmware, resulting in an association failure.
Fix this by finding the first RSN or WPA IE and only adding that. This
has the extra benefit of working properly if the RSN/WPA IE isn't the
first one in the IE buffer.
While we're at it, clean up the code to use the available structs like
the other lbs_add_* functions instead of directly manipulating the TLV
buffer.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123053132.30710-3-doug@schmorgal.com
Doug Brown [Mon, 23 Jan 2023 05:31:29 +0000 (21:31 -0800)]
wifi: libertas: fix code style in Marvell structs
Several of the structs are using the deprecated convention of items[1]
for a dynamically sized trailing element. Convert these structs to the
modern C99 style of items[]. Also fix a couple of camel case struct
element names.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230123053132.30710-2-doug@schmorgal.com
Kalle Valo [Mon, 13 Feb 2023 12:38:27 +0000 (14:38 +0200)]
Merge tag 'mt76-for-kvalo-2023-02-03' of https://github.com/nbd168/wireless
mt76 patches for 6.3
- fixes
- mt7996 cleanups
- switch to page pool allocator
- mt7996 eht support
- WED reset support
Kalle Valo [Mon, 13 Feb 2023 06:58:37 +0000 (08:58 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2023-01-30' of git./linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi updates towards v6.3, this patch-set contains:
* EHT rate reporting
* Sniffer support for EHT and a few fixes in the related code
* A few general cleanups and small bugfixes
* Bump FW API to 74 for AX devices
* Fix a compilation error in mei (it still depends on BROKEN)
* STEP equalizer support - transfer some Phy related parameters from
the BIOS to the firmware
Jakub Kicinski [Sat, 11 Feb 2023 03:50:48 +0000 (19:50 -0800)]
Merge branch '40GbE' of git://git./linux/kernel/git/tnguy/next-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2023-02-09 (i40e)
Jan removes i40e_status from the driver; replacing them with standard
kernel error codes.
Kees Cook replaces 0-length array with flexible array.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
net/i40e: Replace 0-length array with flexible array
i40e: use ERR_PTR error print in i40e messages
i40e: use int for i40e_status
i40e: Remove string printing for i40e_status
i40e: Remove unused i40e status codes
====================
Link: https://lore.kernel.org/r/20230209172536.3595838-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sat, 11 Feb 2023 03:49:55 +0000 (19:49 -0800)]
Merge branch 's390-net-updates-2023-02-06'
Alexandra Winter says:
====================
s390/net: updates 2023-02-06
Just maintenance patches, no functional changes.
If you disagree with patch 4, we can leave it out.
We prefer scnprintf, but no strong opinion.
====================
Link: https://lore.kernel.org/r/20230209110424.1707501-1-wintera@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Thorsten Winkler [Thu, 9 Feb 2023 11:04:24 +0000 (12:04 +0100)]
s390/qeth: Convert sprintf/snprintf to scnprintf
This LWN article explains the rationale for this change
https: //lwn.net/Articles/69419/
Ie. snprintf() returns what *would* be the resulting length,
while scnprintf() returns the actual length.
Reported-by: Jules Irenge <jbi.octave@gmail.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Thorsten Winkler [Thu, 9 Feb 2023 11:04:23 +0000 (12:04 +0100)]
s390/qeth: Convert sysfs sprintf to sysfs_emit
Following the advice of the Documentation/filesystems/sysfs.rst.
All sysfs related show()-functions should only use sysfs_emit() or
sysfs_emit_at() when formatting the value to be returned to user space.
Reported-by: Jules Irenge <jbi.octave@gmail.com>
Reported-by: Joe Perches <joe@perches.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Thorsten Winkler [Thu, 9 Feb 2023 11:04:22 +0000 (12:04 +0100)]
s390/qeth: Use constant for IP address buffers
Use INET6_ADDRSTRLEN constant with size of 48 which be used for char arrays
storing ip addresses (for IPv4 and IPv6)
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com>
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>