<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/wireless/realtek/rtw89/debug.c, branch linux-6.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.2.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-03-10T08:29:13Z</updated>
<entry>
<title>wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30</title>
<updated>2023-03-10T08:29:13Z</updated>
<author>
<name>Zong-Zhe Yang</name>
<email>kevin_yang@realtek.com</email>
</author>
<published>2023-01-19T06:35:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ee9732c0650d339c5e50a0106e6f34873b9e9a50'/>
<id>urn:sha1:ee9732c0650d339c5e50a0106e6f34873b9e9a50</id>
<content type='text'>
[ Upstream commit c074da21dd346e0cfef5d08b0715078d7aea7f8d ]

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 &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20230119063529.61563-2-pkshih@realtek.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: rtw89: update D-MAC and C-MAC dump to diagnose SER</title>
<updated>2022-11-08T07:39:47Z</updated>
<author>
<name>Chia-Yuan Li</name>
<email>leo.li@realtek.com</email>
</author>
<published>2022-11-02T01:43:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f7333fc2135b96dc36965a8e711a9275432256df'/>
<id>urn:sha1:f7333fc2135b96dc36965a8e711a9275432256df</id>
<content type='text'>
To detect TX or RX stuck, we implement SER (system error recovery) in
firmware to recover abnormal states of hardware, and report events to
driver. This kind of events could happen rarely per day.

SER might be true-positive or false-negative cases, and it could be failed
to recover true-positive case. We dump related registers to kernel message
at that moment and collect them from users, because they occur rarely,
randomly and hard to make sure we reproduce the same symptom. To address
problems accurately, add more registers by this patch.

It also might be false-positive cases that looks like TX or RX get stuck,
we need to dump registers from debugfs manually, so also add similar
things to debugfs as well.

Signed-off-by: Chia-Yuan Li &lt;leo.li@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221102014300.14091-3-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: dump dispatch status via debug port</title>
<updated>2022-11-08T07:39:46Z</updated>
<author>
<name>Chia-Yuan Li</name>
<email>leo.li@realtek.com</email>
</author>
<published>2022-11-02T01:42:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d6197c9121dd72f35e5702aa55ee5c1583e0bfdb'/>
<id>urn:sha1:d6197c9121dd72f35e5702aa55ee5c1583e0bfdb</id>
<content type='text'>
Dispatch is a component to decide packets forward to host, DMAC or
HAXIDMA. It contains CDT standing for CPU dispatcher, HDT standing
for host dispatcher, WDE standing for descriptor engine and PLE standing
for payload engine. STF is one kind of modes, it can be used if packet
send to hardware and doesn't need release report.

These debug port information can help to clarify the reason if
packets stuck in dispatch.

Signed-off-by: Chia-Yuan Li &lt;leo.li@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221102014300.14091-2-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: add BW info for both TX and RX in phy_info</title>
<updated>2022-11-01T09:25:28Z</updated>
<author>
<name>Eric Huang</name>
<email>echuang@realtek.com</email>
</author>
<published>2022-10-21T09:16:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=25f49617b5c9c9afa829030f14606be6351d4771'/>
<id>urn:sha1:25f49617b5c9c9afa829030f14606be6351d4771</id>
<content type='text'>
In order to debug performance issue intuitively, add bandwidth information
into debugfs entry phy_info. After applying this patch, it looks like:

 TX rate [0]: HE 2SS MCS-11 GI:0.8 BW:80 (hw_rate=0x19b) ==&gt; agg_wait=1 (3500)
 RX rate [0]: HE 2SS MCS-9 GI:0.8 BW:80  (hw_rate=0x199)

Signed-off-by: Eric Huang &lt;echuang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20221021091601.39884-1-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: add to dump TX FIFO 0/1 for 8852C</title>
<updated>2022-10-05T07:43:19Z</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2022-09-30T13:44:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=732dd91db3d3a1b7a767598549ffed358c9fbb89'/>
<id>urn:sha1:732dd91db3d3a1b7a767598549ffed358c9fbb89</id>
<content type='text'>
MAC maintains TX FIFO to transmit packets with meta data to BB layer. To
debug abnormal transmission, we need to dump the content to dig problem.
Since FIFO of 8852C locates on different address with different size and
need additional switch to enable read operation, this patch adds the
changes accordingly.

Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20220930134417.10282-2-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: debug: txpwr_table considers sign</title>
<updated>2022-10-04T07:17:37Z</updated>
<author>
<name>Zong-Zhe Yang</name>
<email>kevin_yang@realtek.com</email>
</author>
<published>2022-09-28T08:43:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b902161645879ac820dfbb561667cd08be569538'/>
<id>urn:sha1:b902161645879ac820dfbb561667cd08be569538</id>
<content type='text'>
Previously, value of each field is just shown as unsigned.
Now, we start to show them with sign to make things more intuitive
during debugging.

Signed-off-by: Zong-Zhe Yang &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20220928084336.34981-6-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: support SER L1 simulation</title>
<updated>2022-09-19T10:03:38Z</updated>
<author>
<name>Zong-Zhe Yang</name>
<email>kevin_yang@realtek.com</email>
</author>
<published>2022-09-14T03:50:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8a1f6c88462120ea472b9b7f09afa84104b43391'/>
<id>urn:sha1:8a1f6c88462120ea472b9b7f09afa84104b43391</id>
<content type='text'>
SER (system error recovery) can deal with different crash types by
different levels of processes. Previous FW crash simulation triggers
a CPU exception which is one kind of SER L2 type. It can verify SER L2
flow which includes HW/FW restart.

Now, we want to increase crash simulation types. A debug function is added
to trigger control error in purpose for SER L1 simulation/verification.
And, debugfs fw_crash is extended to accept different parameters.

echo 1 &gt; fw_crash:
	simulate CPU exception as before
	(keep 1 for compatibility with previous)

	It will be catched and handled by SER L2.
	(this requires HW/FW restart)

echo 2 &gt; fw_crash:
	simulate control error

	It will be catched and handled by SER L1.
	(driver and FW cooperate to recover this)

Besides, in order to apply to the above two cases,
rename RTW89_FLAG_RESTART_TRIGGER to RTW89_FLAG_CRASH_SIMULATING
and adjust where SER flow clears this bit for both L1 and L2.

Signed-off-by: Zong-Zhe Yang &lt;kevin_yang@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20220914035034.14521-5-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: support TX diversity for 1T2R chipset</title>
<updated>2022-09-12T11:51:44Z</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2022-09-08T07:41:40Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7dbdf65525b365261904d427978009fe22f937b3'/>
<id>urn:sha1:7dbdf65525b365261904d427978009fe22f937b3</id>
<content type='text'>
Check RSSI strength to decide which path is better, and then set TX path
accordingly.

Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20220908074140.39776-6-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: rtw89: record signal strength per RF path</title>
<updated>2022-09-12T11:51:44Z</updated>
<author>
<name>Ping-Ke Shih</name>
<email>pkshih@realtek.com</email>
</author>
<published>2022-09-08T07:41:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6ce472d6516ce1ff0d5ae3f54578d118d93f6c16'/>
<id>urn:sha1:6ce472d6516ce1ff0d5ae3f54578d118d93f6c16</id>
<content type='text'>
Originally, we show average signal strength. To support TX diversity, this
patch prepares strength per path, then we can decide TX path.

  RSSI: -54 dBm (raw=112, prev=110) [-57, -52]

Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@kernel.org&gt;
Link: https://lore.kernel.org/r/20220908074140.39776-5-pkshih@realtek.com
</content>
</entry>
<entry>
<title>wifi: mac80211: keep A-MSDU data in sta and per-link</title>
<updated>2022-09-06T08:17:08Z</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2022-09-02T14:12:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4c51541ddb78cef2da9c4c30006c0d9d06ea9a77'/>
<id>urn:sha1:4c51541ddb78cef2da9c4c30006c0d9d06ea9a77</id>
<content type='text'>
The A-MSDU data needs to be stored per-link and aggregated into a single
value for the station. Add a new struct ieee_80211_sta_aggregates in
order to store this data and a new function
ieee80211_sta_recalc_aggregates to update the current data for the STA.

Note that in the non MLO case the pointer in ieee80211_sta will directly
reference the data in deflink.agg, which means that recalculation may be
skipped in that case.

Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
