<feed xmlns='http://www.w3.org/2005/Atom'>
<title>starfive-tech/linux.git/drivers/net/wireless/realtek, branch visionfive</title>
<subtitle>StarFive Tech Linux Kernel for VisionFive (JH7110) boards (mirror)</subtitle>
<id>https://git.radix-linux.su/starfive-tech/linux.git/atom?h=visionfive</id>
<link rel='self' href='https://git.radix-linux.su/starfive-tech/linux.git/atom?h=visionfive'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/'/>
<updated>2025-07-24T07:05:31+00:00</updated>
<entry>
<title>wifi: Fix typos</title>
<updated>2025-07-24T07:05:31+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2025-07-23T20:17:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=41469ff94c052b4900af85f1c62a17aff6236f42'/>
<id>urn:sha1:41469ff94c052b4900af85f1c62a17aff6236f42</id>
<content type='text'>
Fix typos in comments and error messages.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Link: https://patch.msgid.link/20250723201741.2908456-1-helgaas@kernel.org
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: mac80211: don't require cipher and keylen in gtk rekey</title>
<updated>2025-07-22T08:43:19+00:00</updated>
<author>
<name>Miri Korenblit</name>
<email>miriam.rachel.korenblit@intel.com</email>
</author>
<published>2025-07-21T18:50:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=69fdb084355d6c0b353536024cc51aa5f7ffb62c'/>
<id>urn:sha1:69fdb084355d6c0b353536024cc51aa5f7ffb62c</id>
<content type='text'>
ieee80211_add_gtk_rekey receives a keyconf as an argument, and the
cipher and keylen are taken from there to the new allocated key.
But in rekey, both the cipher and the keylen should be the same as of
the old key, so let ieee80211_add_gtk_rekey find those, so drivers won't
have to fill it in.

Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20250721214922.3c5c023bfae9.Ie6594ae2b4b6d5b3d536e642b349046ebfce7a5d@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: rtlwifi: Use min()/max() to improve code</title>
<updated>2025-07-18T06:41:06+00:00</updated>
<author>
<name>Qianfeng Rong</name>
<email>rongqianfeng@vivo.com</email>
</author>
<published>2025-07-15T12:16:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=94cd0ba1842ece06acc15bba5f2bff6b6043eb1d'/>
<id>urn:sha1:94cd0ba1842ece06acc15bba5f2bff6b6043eb1d</id>
<content type='text'>
Use min()/max() to reduce the code and improve its readability.

Acked-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Qianfeng Rong &lt;rongqianfeng@vivo.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20250715121721.266713-8-rongqianfeng@vivo.com
</content>
</entry>
<entry>
<title>wifi: rtw89: wow: Add Basic Rate IE to probe request in scheduled scan mode</title>
<updated>2025-07-18T06:36:56+00:00</updated>
<author>
<name>Chin-Yen Lee</name>
<email>timlee@realtek.com</email>
</author>
<published>2025-07-16T12:29:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=37c23874d13eb369d8b384a1ce5992ff6c23d56f'/>
<id>urn:sha1:37c23874d13eb369d8b384a1ce5992ff6c23d56f</id>
<content type='text'>
In scheduled scan mode, the current probe request only includes the SSID
IE, but omits the Basic Rate IE. Some APs do not respond to such
incomplete probe requests, causing net-detect failures. To improve
interoperability and ensure APs respond correctly, add the Basic Rate IE
to the probe request in driver.

Signed-off-by: Chin-Yen Lee &lt;timlee@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20250716122926.6709-1-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: Lower the timeout in rtw89_fwdl_check_path_ready_ax() for USB</title>
<updated>2025-07-18T06:22:35+00:00</updated>
<author>
<name>Bitterblue Smith</name>
<email>rtl8821cerfe2@gmail.com</email>
</author>
<published>2025-07-15T19:46:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=12322a02603071d09df652bbc11864e23de0b83e'/>
<id>urn:sha1:12322a02603071d09df652bbc11864e23de0b83e</id>
<content type='text'>
When the chip is not powered on correctly (like during driver
development) rtw89_fwdl_check_path_ready_ax() can fail.
read_poll_timeout_atomic() with a delay of 1 µs and a timeout of
400000 µs can take 50 seconds with USB because of the time it takes to
send a USB control message. The firmware upload is tried 5 times, so
in total it takes 250 seconds.

Lower the timeout to 3200 for USB in order to reduce the time
rtw89_fwdl_check_path_ready_ax() takes from 50 seconds to less than 1
second.

Signed-off-by: Bitterblue Smith &lt;rtl8821cerfe2@gmail.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/af0b25d0-ea67-455e-91f2-8e4c18ae4328@gmail.com
</content>
</entry>
<entry>
<title>wifi: rtw89: Lower the timeout in rtw89_fw_read_c2h_reg() for USB</title>
<updated>2025-07-18T06:21:29+00:00</updated>
<author>
<name>Bitterblue Smith</name>
<email>rtl8821cerfe2@gmail.com</email>
</author>
<published>2025-07-15T19:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=671be46afd1f03de9dc6e4679c88e1a7a81cdff6'/>
<id>urn:sha1:671be46afd1f03de9dc6e4679c88e1a7a81cdff6</id>
<content type='text'>
This read_poll_timeout_atomic() with a delay of 1 µs and a timeout of
1000000 µs can take ~250 seconds in the worst case because sending a
USB control message takes ~250 µs.

Lower the timeout to 4000 for USB in order to reduce the maximum polling
time to ~1 second.

This problem was observed with RTL8851BU while suspending to RAM with
WOWLAN enabled. The computer sat for 4 minutes with a black screen
before suspending.

Signed-off-by: Bitterblue Smith &lt;rtl8821cerfe2@gmail.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/09313da6-c865-4e91-b758-4cb38a878796@gmail.com
</content>
</entry>
<entry>
<title>wifi: rtw89: check path range before using in rtw89_fw_h2c_rf_ps_info()</title>
<updated>2025-07-18T06:03:34+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2025-07-15T03:52:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=8b4a0277388137ac31728ee69d9e388a0fa52287'/>
<id>urn:sha1:8b4a0277388137ac31728ee69d9e388a0fa52287</id>
<content type='text'>
The variable 'path' from rtw89_phy_get_syn_sel() as index of array could
be 3, but array size is 2. Fortunately, current chip-&gt;rf_path_num is
smaller or equal to 2, so it is safe. To prevent mistakes in the future,
add a checking and avoid Coverity warnings.

Addresses-Coverity-ID: linux-next: 1644716 ("Out-of-bounds write")
Addresses-Coverity-ID: linux-next: 1644717 ("Out-of-bounds write")

Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20250715035259.45061-6-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: purge obsoleted scan events with software sequence number</title>
<updated>2025-07-18T06:02:03+00:00</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2025-07-15T03:52:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=f1000385d47be9e0a1d1d622a2e2e28ffd0fe384'/>
<id>urn:sha1:f1000385d47be9e0a1d1d622a2e2e28ffd0fe384</id>
<content type='text'>
The queued and obsoleted scan events can be wrongly treated as events of
new scan request, causing unexpected scan result. Attach a software
sequence number to scan request and its corresponding events. When a new
scan request is acknowledged by firmware, purge the scan events if its
sequence number is not belong to current request.

Normal case:

   mac80211                   event work        event BH
   -------------              ----------        --------
   scan req #1 ----&gt;o
                    |
               &lt;----o  &lt;...........................o
                                  o
                                  |
       &lt;--------------------------+
         ieee80211_scan_completed()

Abnormal case (late event work):

   mac80211                   event work        event BH
   -------------              ----------        --------
   scan req #1 ----&gt;o
                    |
               &lt;----o  &lt;...........................o
                                  o #1

   scan cancel #2 -&gt;o
                    |
               &lt;----o  &lt;...........................o
                                  o #2
                                  | (patch to avoid this)
   scan req #3 ----&gt;o             |
                    |             |
               &lt;----o  &lt;..........|................o
                                  | o #3
       &lt;--------------------------+
         ieee80211_scan_completed()

Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20250715035259.45061-5-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: dynamically update EHT preamble puncturing</title>
<updated>2025-07-18T06:00:33+00:00</updated>
<author>
<name>Kuan-Chung Chen</name>
<email>damon.chen@realtek.com</email>
</author>
<published>2025-07-15T03:52:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=b552a3ef8a3d722470593349333c9b19bfe40767'/>
<id>urn:sha1:b552a3ef8a3d722470593349333c9b19bfe40767</id>
<content type='text'>
When the 'Disabled Subchannel Bitmap' within the EHT Operation
element is changed, mac80211 parse and pass it to the driver.
The driver is then updated with this puncturing bitmap to
optimize bandwidth usage and prevent interference from
degrading performance across the entire channel.

Signed-off-by: Kuan-Chung Chen &lt;damon.chen@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20250715035259.45061-4-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: mac: reduce PPDU status length for WiFi 6 chips</title>
<updated>2025-07-18T06:00:20+00:00</updated>
<author>
<name>Chia-Yuan Li</name>
<email>leo.li@realtek.com</email>
</author>
<published>2025-07-15T03:52:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/starfive-tech/linux.git/commit/?id=8552f2b3153eb8d49450f1661adf62457c410660'/>
<id>urn:sha1:8552f2b3153eb8d49450f1661adf62457c410660</id>
<content type='text'>
Since the RX counter in the PPDU status is not used,
it is disabled to reduce the waste of DLE quota.

Signed-off-by: Chia-Yuan Li &lt;leo.li@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20250715035259.45061-3-pkshih@realtek.com
</content>
</entry>
</feed>
