Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)

[LB F]

Hi Bitterblue, Ping-Ke,

Please excuse the quick follow-up to my previous email. After looking
at the code again, I realized my previous suggestion (changing the
`query_phy_status` callback to return an `int`) was unnecessarily
invasive, as it would require touching the `ops` struct for all
chipsets.

I wanted to share a much simpler alternative that I found, which seems
to address the issue of invalid PHY status pages without any
structural changes.

Currently, when `query_phy_status()` encounters an invalid page (the
`default:` case), it prints the "unused phy status page" warning and
returns, leaving `pkt_stat->phy_status` set to true, but the actual
signal and RSSI values uninitialized (zero).

This leads to two minor issues downstream:
1. In `rtw_rx_fill_rx_status()`, mac80211 gets passed a false `signal=0` value.
2. In `rtw_rx_addr_match()`, the frame passes the
`!pkt_stat->phy_status` check, causing `ewma_rssi_add(&si->avg_rssi,
pkt_stat->rssi)` to be called with a 0 value, which corrupts the
moving average of the RSSI.

It seems this could be completely resolved by simply adding one line
to the `default:` case in `query_phy_status()` (e.g., in
`rtw8821c.c`):

--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
@@ -677,6 +677,7 @@ static void query_phy_status(struct rtw_dev
*rtwdev, u8 *phy_status,
  break;
  default:
  rtw_warn(rtwdev, "unused phy status page (%d)\n", page);
+ pkt_stat->phy_status = false;
  return;
  }
 }

By explicitly marking the PHY status as invalid before returning:
- `rtw_rx_fill_rx_status()` will correctly fall into the `else` block
and set `rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;`.
- `rtw_rx_addr_match()` will correctly early-return, protecting the
RSSI moving average.

The frame itself is still passed to mac80211 (since the payload might
be valid), but without the bogus signal metadata.

Again, this is just an amateur observation from reviewing the code
while testing the recent RX descriptor patches. The current patches
are running flawlessly on my end. I leave it to your expertise to
decide if this one-line addition is worthwhile.

Best regards,
Oleksandr Havrylov