[PATCH] wifi: rtw88: Add NULL check for chip->edcca_th

[PATCH] wifi: rtw88: Add NULL check for chip->edcca_th

[Panagiotis Petrakopoulos]

It was recently reported that rtw_fw_adaptivity_result
in fw.c dereferences rtwdev->chip->edcca_th without
a null check. The issue appears to be that devices
with the 8821CE chip don't define edcca_th in their
chip info. As a result, when rtw_fw_adaptivity_result
tries to dereference it, the kernel triggers an oops.

Add a NULL check for edcca_th before dereferencing
it in rtw_fw_adaptivity_result() in fw.c and
rtw_phy_set_edcca_th() in phy.c.

Tested on a 8822CE chip which defines edcca_th, so
this issue is not present on it, but it still uses
this driver and I can verify there are no regressions.

Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Link: https://lore.kernel.org/linux-wireless/CALdGYqQriS7mP0vj_rm_xvisfzFVh0hbpy+---48r6bodZO7tg@mail.gmail.com/
Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
---
 drivers/net/wireless/realtek/rtw88/fw.c  | 3 +++
 drivers/net/wireless/realtek/rtw88/phy.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index 48207052e3f8..c4819ef6d54d 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -284,6 +284,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
 		result->density, result->igi, result->l2h_th_init, result->l2h,
 		result->h2l, result->option);
 
+	if (!edcca_th)
+		return;
+
 	rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
 		rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
 				edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
index e2ac5c6fd500..c10eb28e54ad 100644
--- a/drivers/net/wireless/realtek/rtw88/phy.c
+++ b/drivers/net/wireless/realtek/rtw88/phy.c
@@ -161,6 +161,9 @@ void rtw_phy_set_edcca_th(struct rtw_dev *rtwdev, u8 l2h, u8 h2l)
 {
 	const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
 
+	if (!edcca_th)
+		return;
+
 	rtw_write32_mask(rtwdev,
 			 edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
 			 edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask,
-- 
2.53.0

Re: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th

[LB F]

Hi Panagiotis,

Thank you for your interest and for looking into this issue!

I appreciate the effort, but as I'm not a developer, I would prefer to
wait for a review and approval from the maintainer (Ping-Ke Shih)
before testing or applying any patch — to make sure everything stays
consistent with the official direction.

Ping-Ke, could you please take a look at this patch when you have a
chance? If you approve the approach, I'll be happy to test it and
provide a Tested-by.

Best regards, Oleksandr Havrylov

RE: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th

[Ping-Ke Shih]

+ Bitterblue

Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com> wrote:
> It was recently reported that rtw_fw_adaptivity_result
> in fw.c dereferences rtwdev->chip->edcca_th without
> a null check. The issue appears to be that devices
> with the 8821CE chip don't define edcca_th in their
> chip info. As a result, when rtw_fw_adaptivity_result
> tries to dereference it, the kernel triggers an oops.
> 
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c and
> rtw_phy_set_edcca_th() in phy.c.
> 
> Tested on a 8822CE chip which defines edcca_th, so
> this issue is not present on it, but it still uses
> this driver and I can verify there are no regressions.
> 
> Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
> Link:
> https://lore.kernel.org/linux-wireless/CALdGYqQriS7mP0vj_rm_xvisfzFVh0hbpy+---48r6bodZO7tg@mail.gm
> ail.com/
> Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
> ---
>  drivers/net/wireless/realtek/rtw88/fw.c  | 3 +++
>  drivers/net/wireless/realtek/rtw88/phy.c | 3 +++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
> index 48207052e3f8..c4819ef6d54d 100644
> --- a/drivers/net/wireless/realtek/rtw88/fw.c
> +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> @@ -284,6 +284,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
>                 result->density, result->igi, result->l2h_th_init, result->l2h,
>                 result->h2l, result->option);
> 
> +       if (!edcca_th)
> +               return;
> +

As Bitterblue analysis, this might be a garbage, so I'd return at the entry
of this function.

>         rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
>                 rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
>                                 edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
> diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
> index e2ac5c6fd500..c10eb28e54ad 100644
> --- a/drivers/net/wireless/realtek/rtw88/phy.c
> +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> @@ -161,6 +161,9 @@ void rtw_phy_set_edcca_th(struct rtw_dev *rtwdev, u8 l2h, u8 h2l)
>  {
>         const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
> 
> +       if (!edcca_th)
> +               return;
> +

The callers of rtw_phy_set_edcca_th() are RTL8822B and RTL8822C, which both
define rtwdev->chip->edcca_th. How can edcca_th be NULL?

>         rtw_write32_mask(rtwdev,
>                          edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
>                          edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask,
> --
> 2.53.0

RE: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th

[Ping-Ke Shih]

Hi Oleksandr,

LB F <goainwo@gmail.com> wrote:
> Ping-Ke, could you please take a look at this patch when you have a
> chance? If you approve the approach, I'll be happy to test it and
> provide a Tested-by.

I remember Bitterblue is still making a test patch, and this patch is one
to avoid garbage RX. If we can validate size or other clues at earlier of
RX data path, this malformed packet might not go into this function.

This reminds me, the patch getting merged to checking VHT rate seems to
be another clue of malformed packets. Maybe, we should just drop the
packets instead, which the content might be just a garbage. 

Ping-Ke

Re: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th

[Panagiotis Petrakopoulos]

On Tue, Apr 14, 2026 at 5:03 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
> > diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
> > index 48207052e3f8..c4819ef6d54d 100644
> > --- a/drivers/net/wireless/realtek/rtw88/fw.c
> > +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> > @@ -284,6 +284,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
> >                 result->density, result->igi, result->l2h_th_init, result->l2h,
> >                 result->h2l, result->option);
> >
> > +       if (!edcca_th)
> > +               return;> >
> As Bitterblue analysis, this might be a garbage, so I'd return at the entry
> of this function.
>
> >         rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
> >                 rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> >                                 edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
> > diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
> > index e2ac5c6fd500..c10eb28e54ad 100644
> > --- a/drivers/net/wireless/realtek/rtw88/phy.c
> > +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> > @@ -161,6 +161,9 @@ void rtw_phy_set_edcca_th(struct rtw_dev *rtwdev, u8 l2h, u8 h2l)
> >  {
> >         const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
> >
> > +       if (!edcca_th)
> > +               return;
> > +
>
> The callers of rtw_phy_set_edcca_th() are RTL8822B and RTL8822C, which both
> define rtwdev->chip->edcca_th. How can edcca_th be NULL?
>
> >         rtw_write32_mask(rtwdev,
> >                          edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> >                          edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask,
> > --
> > 2.53.0
>
Hello! Thanks for the swift review. It looks like the right call to
move the early return to the entry of the function given that the
values are corrupted. You're also right about rtw_phy_set_edcca_th. I
missed the callers. Upon checking, it's just the chips you mentioned.
I'll drop that for the v2

[PATCH v2] wifi: rtw88: Add NULL check for chip->edcca_th

[Panagiotis Petrakopoulos]

It was recently reported that rtw_fw_adaptivity_result()
in fw.c dereferences rtwdev->chip->edcca_th without
a NULL check. The issue is that devices with the
8821CE chip don't define edcca_th in their chip
info. As a result, when rtw_fw_adaptivity_result()
tries to dereference it, the kernel triggers an oops.

Add a NULL check for edcca_th before dereferencing
it in rtw_fw_adaptivity_result() in fw.c. Placing
the check at the function entry avoids logging any
garbage values.

This change does not address the root cause for
this behavior, but it prevents the NULL dereference
and the resulting oops while a more permanent solution
is developed.

Tested on a 8822CE chip which defines edcca_th, so
this issue is not present on it, but it still uses
this driver and I can verify there are no regressions.

Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Link: https://lore.kernel.org/linux-wireless/CALdGYqQriS7mP0vj_rm_xvisfzFVh0hbpy+---48r6bodZO7tg@mail.gmail.com/
Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
---
v2:
  - Move NULL check to the entry of rtw_fw_adaptivity_result() (Ping-Ke Shih)
  - Drop rtw_phy_set_edcca_th() hunk; all callers define edcca_th (Ping-Ke Shih)
  - Change bugzilla reference from Closes: to Link: since this does not
    address the root cause

 drivers/net/wireless/realtek/rtw88/fw.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index 48207052e3f8..945fedcd375b 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -279,6 +279,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
 	const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
 	struct rtw_c2h_adaptivity *result = (struct rtw_c2h_adaptivity *)payload;
 
+	if (!edcca_th)
+		return;
+
 	rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY,
 		"Adaptivity: density %x igi %x l2h_th_init %x l2h %x h2l %x option %x\n",
 		result->density, result->igi, result->l2h_th_init, result->l2h,
-- 
2.53.0

RE: [PATCH v2] wifi: rtw88: Add NULL check for chip->edcca_th

[Ping-Ke Shih]

Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com> wrote:
> 
> It was recently reported that rtw_fw_adaptivity_result()
> in fw.c dereferences rtwdev->chip->edcca_th without
> a NULL check. The issue is that devices with the
> 8821CE chip don't define edcca_th in their chip
> info. As a result, when rtw_fw_adaptivity_result()
> tries to dereference it, the kernel triggers an oops.
> 
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c. 

I'd point out function name in subject as 
"wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()"

> Placing
> the check at the function entry avoids logging any
> garbage values.
> 
> This change does not address the root cause for
> this behavior, but it prevents the NULL dereference
> and the resulting oops while a more permanent solution
> is developed.
> 
> Tested on a 8822CE chip which defines edcca_th, so
> this issue is not present on it, but it still uses
> this driver and I can verify there are no regressions.
> 
> Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
> Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221286

I'd change Link tag to Closes.

> Link:
> https://lore.kernel.org/linux-wireless/CALdGYqQriS7mP0vj_rm_xvisfzFVh0hbpy+---48r6bodZO7tg@mail.gm
> ail.com/

I can preserve this Link, but actually the thread contains more than one
things.

> Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

> ---
> v2:
>   - Move NULL check to the entry of rtw_fw_adaptivity_result() (Ping-Ke Shih)
>   - Drop rtw_phy_set_edcca_th() hunk; all callers define edcca_th (Ping-Ke Shih)
>   - Change bugzilla reference from Closes: to Link: since this does not
>     address the root cause

Even this is a workaround, I think we can still use Closes and mark the
bugzilla resolved. 

> 
>  drivers/net/wireless/realtek/rtw88/fw.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
> index 48207052e3f8..945fedcd375b 100644
> --- a/drivers/net/wireless/realtek/rtw88/fw.c
> +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> @@ -279,6 +279,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
>         const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
>         struct rtw_c2h_adaptivity *result = (struct rtw_c2h_adaptivity *)payload;
> 
> +       if (!edcca_th)
> +               return;
> +
>         rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY,
>                 "Adaptivity: density %x igi %x l2h_th_init %x l2h %x h2l %x option %x\n",
>                 result->density, result->igi, result->l2h_th_init, result->l2h,
> --
> 2.53.0

[PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()

[Panagiotis Petrakopoulos]

It was recently reported that rtw_fw_adaptivity_result()
in fw.c dereferences rtwdev->chip->edcca_th without
a NULL check. The issue is that devices with the
8821CE chip don't define edcca_th in their chip
info. As a result, when rtw_fw_adaptivity_result()
tries to dereference it, the kernel triggers an oops.

Add a NULL check for edcca_th before dereferencing
it in rtw_fw_adaptivity_result() in fw.c. Placing
the check at the function entry avoids logging any
garbage values.

This change does not address the root cause for
this behavior, but it prevents the NULL dereference
and the resulting oops while a more permanent solution
is developed.

Tested on a 8822CE chip which defines edcca_th, so
this issue is not present on it, but it still uses
this driver and I can verify there are no regressions.

Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
---
v3:
  - Include function name in subject (Ping-Ke Shih)
  - Restore the Closes: tag for bugzilla (Ping-Ke Shih)
  - Drop the lore Link: tag

v2:
  - Move NULL check to the entry of rtw_fw_adaptivity_result() (Ping-Ke Shih)
  - Drop rtw_phy_set_edcca_th() hunk; all callers define edcca_th (Ping-Ke Shih)
  - Change bugzilla reference from Closes: to Link: since this does not
    address the root cause

 drivers/net/wireless/realtek/rtw88/fw.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index 48207052e3f8..945fedcd375b 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -279,6 +279,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
 	const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
 	struct rtw_c2h_adaptivity *result = (struct rtw_c2h_adaptivity *)payload;

+	if (!edcca_th)
+		return;
+
 	rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY,
 		"Adaptivity: density %x igi %x l2h_th_init %x l2h %x h2l %x option %x\n",
 		result->density, result->igi, result->l2h_th_init, result->l2h,
--
2.53.0

RE: [PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()

[Ping-Ke Shih]

Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com> wrote:
> It was recently reported that rtw_fw_adaptivity_result()
> in fw.c dereferences rtwdev->chip->edcca_th without
> a NULL check. The issue is that devices with the
> 8821CE chip don't define edcca_th in their chip
> info. As a result, when rtw_fw_adaptivity_result()
> tries to dereference it, the kernel triggers an oops.
> 
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c. Placing
> the check at the function entry avoids logging any
> garbage values.
> 
> This change does not address the root cause for
> this behavior, but it prevents the NULL dereference
> and the resulting oops while a more permanent solution
> is developed.
> 
> Tested on a 8822CE chip which defines edcca_th, so
> this issue is not present on it, but it still uses
> this driver and I can verify there are no regressions.
> 
> Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
> Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
> Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

Re: [PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()

[LB F]

On Tue, 15 Apr 2026, Panagiotis Petrakopoulos wrote:
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c.

Hi Panagiotis,

I have applied this v3 patch to my local out-of-tree rtw88 build
(openSUSE Tumbleweed, kernel 6.19) on the affected RTL8821CE
hardware. The driver compiles cleanly and the module loads
without issues.

I am now starting a structured stability test covering suspend,
hibernation, high-throughput transfers, and long uptime. I will
follow up with a Tested-by once I have sufficient confidence in
the results.

Best regards,
Oleksandr Havrylov

Re: [PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()

[LB F]

On Tue, 15 Apr 2026, Panagiotis Petrakopoulos wrote:
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c.

Hi Panagiotis, hi Ping-Ke,

Following up on my preliminary note from yesterday — I have now
completed a structured 27-hour stability test on the affected RTL8821CE
hardware with the full set of patches applied.

Test environment:
  - Hardware:   HP Notebook (DMI: HP P3S95EA#ACB)
  - Chip:       RTL8821CE (PCI ID: 10ec:c821)
  - OS:         openSUSE Tumbleweed (Slowroll)
  - Kernel:     6.19
  - Driver:     lwfinger/rtw88 out-of-tree (DKMS)

Patches applied on top of the out-of-tree driver:
  1. [rtw-next] wifi: rtw88: add quirks to disable PCI ASPM and deep
     LPS for HP P3S95EA#ACB (Ping-Ke Shih) — pci.c / main.h
  2. [PATCH v2 rtw-next] wifi: rtw88: validate RX rate to prevent
     out-of-bound (Ping-Ke Shih) — rx.c
  3. Diagnostic hex dump patch (Bitterblue Smith) — rtw8821c.c;
     logs raw RX descriptor data on "unused phy status page" events
  4. [PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in
     rtw_fw_adaptivity_result() (Panagiotis Petrakopoulos) — fw.c

All four patches were verified to be present in the compiled
.ko.zst module binaries before testing began.

Test methodology:
  - Continuous ping (50 packets, 0% loss)
  - High-throughput RX: 100 MB file download (~6 MB/s sustained)
  - Bluetooth A2DP coexistence (Soundcore Q10i) with simultaneous
    WiFi traffic
  - Suspend to RAM (S3) and resume
  - Suspend to Disk / Hibernate (S4) and resume (**)
  - Reboot — verified DKMS modules reload with DMI quirk flags active
    (disable_aspm=Y, disable_lps_deep=Y)
  - Download interrupted by suspend mid-transfer, followed by resume
  - 27 hours of general-purpose uptime

(**) Hibernate (S4) was the most critical scenario, as the original
    crash reports correlated garbage RX bursts with post-resume
    conditions, typically within ~90 seconds after the adapter
    re-initialized.

Results:
  - Zero kernel oops, panics, or system hangs across all test scenarios
  - Zero "unexpected RX rate" events
  - WiFi reconnected cleanly and automatically after every
    suspend/hibernate/reboot cycle
  - 3 isolated "unused phy status page" events were observed during
    the first ~2 hours of uptime (pages 7, 9, 10), with zero
    additional occurrences over the remaining 25+ hours

Those 3 isolated events confirm that the hardware still generates
the garbage RX data described in Bug #221286. However, the NULL
check now causes rtw_fw_adaptivity_result() to return early before
dereferencing chip->edcca_th, preventing the oops entirely. The
system handled all three events silently and continued operating
without any disruption.

The hex dumps below were captured by Bitterblue Smith's diagnostic
patch (patch #3 above), which instruments rtw8821c.c to call
print_hex_dump() on every "unused phy status page" event. This
confirms the diagnostic patch is functioning correctly alongside
the NULL check:

  [ 5366.904709] rtw_8821ce 0000:13:00.0: unused phy status page (7)
  [ 5366.904723] 00000000: 4c5635d5 174b302f 0945df3e f4ebe6d8  .5VL/0K.>E......
  [ 5366.904728] 00000010: 08726c23 3e7be907 8a76d3a7 cd252c75  #lr..{>.v..u,%.
  [ 5366.904738] 00000000: 88 42 80 00 8c c8 4b 68 d1 63 6c 68  .B....Kh.clh
  [ 5366.904742] 00000010: a4 1c 97 5b 6c 68 a4 1c 97 5a 00 43  ...[lh...Z.C

The rxdesc portion (lower dump) shows recognizable 802.11 QoS Data
frame headers with the adapter's own MAC address (8c:c8:4b:68:d1:63)
and the AP BSSID (6c:68:a4:1c:97:5b), fully consistent with the
garbage RX pattern documented in Bug #221286. The phy_status portion
(upper dump) is random noise with no valid structure — exactly as
Bitterblue Smith described.

Tested-by: Oleksandr Havrylov <goainwo@gmail.com>

Thank you to Panagiotis for authoring the fix, to Ping-Ke for the
prompt review and Acked-by, and to Bitterblue Smith for the
invaluable diagnostic groundwork that made it possible to understand
and reproduce this issue correctly.

Best regards,
Oleksandr Havrylov

Re: [PATCH v3] wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()

[Panagiotis Petrakopoulos]

I'm very glad it works. Thank you for testing it Oleksandr!