[PATCH] accel/qaic: fix incorrect counter check in RAS message decode

[PATCH] accel/qaic: fix incorrect counter check in RAS message decode

[Alok Tiwari]

The UE and UE_NF cases check ce_count against UINT_MAX before incrementing
their respective counters. This is logically incorrect and prevents
ue_count and ue_nf_count from incrementing when ce_count reaches UINT_MAX.

Fixes: c11a50b170e7 ("accel/qaic: Add Reliability, Accessibility, Serviceability (RAS)")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
---
 drivers/accel/qaic/qaic_ras.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/accel/qaic/qaic_ras.c b/drivers/accel/qaic/qaic_ras.c
index cc0b75461e1a..6791af366cba 100644
--- a/drivers/accel/qaic/qaic_ras.c
+++ b/drivers/accel/qaic/qaic_ras.c
@@ -497,11 +497,11 @@ static void decode_ras_msg(struct qaic_device *qdev, struct ras_data *msg)
 			qdev->ce_count++;
 		break;
 	case UE:
-		if (qdev->ce_count != UINT_MAX)
+		if (qdev->ue_count != UINT_MAX)
 			qdev->ue_count++;
 		break;
 	case UE_NF:
-		if (qdev->ce_count != UINT_MAX)
+		if (qdev->ue_nf_count != UINT_MAX)
 			qdev->ue_nf_count++;
 		break;
 	default:
-- 
2.50.1

Re: [PATCH] accel/qaic: fix incorrect counter check in RAS message decode

[Jeff Hugo]

On 4/10/2026 5:20 AM, Alok Tiwari wrote:
> The UE and UE_NF cases check ce_count against UINT_MAX before incrementing
> their respective counters. This is logically incorrect and prevents
> ue_count and ue_nf_count from incrementing when ce_count reaches UINT_MAX.

Nice catch. I'm curious, how did you find this?

-Jeff

Re: [PATCH] accel/qaic: fix incorrect counter check in RAS message decode

[Jeff Hugo]

On 4/10/2026 5:20 AM, Alok Tiwari wrote:
> The UE and UE_NF cases check ce_count against UINT_MAX before incrementing
> their respective counters. This is logically incorrect and prevents
> ue_count and ue_nf_count from incrementing when ce_count reaches UINT_MAX.
> 
> Fixes: c11a50b170e7 ("accel/qaic: Add Reliability, Accessibility, Serviceability (RAS)")
> Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>

Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>

Claude review: accel/qaic: fix incorrect counter check in RAS message decode

[Claude Code Review Bot]

Overall Series Review

Subject: accel/qaic: fix incorrect counter check in RAS message decode
Author: Alok Tiwari <alok.a.tiwari@oracle.com>
Patches: 3
Reviewed: 2026-04-12T09:40:28.470501

---

This is a single-patch fix for a clear copy-paste bug in the QAIC accelerator RAS (Reliability, Accessibility, Serviceability) error counter logic. The fix is correct, minimal, and obviously right. The bug was introduced in commit c11a50b170e7 and causes `ue_count` and `ue_nf_count` to be gated by the wrong overflow check — they look at `ce_count` instead of their own counter. This means those counters stop incrementing once `ce_count` (not the relevant counter) saturates at `UINT_MAX`, which is both functionally wrong and could mask uncorrectable error reporting.

**Verdict: This patch should be accepted.**

---
Generated by Claude Code Patch Reviewer

Claude review: accel/qaic: fix incorrect counter check in RAS message decode

[Claude Code Review Bot]

Patch Review

**Status: Looks good / Correct fix**

The bug is in `decode_ras_msg()` at `drivers/accel/qaic/qaic_ras.c:500,504`. The switch statement handles three RAS error types — `CE`, `UE`, and `UE_NF` — and each case should check its own counter against `UINT_MAX` before incrementing to prevent overflow. However, the `UE` and `UE_NF` cases both incorrectly check `ce_count`:

```c
case UE:
	if (qdev->ce_count != UINT_MAX)   // BUG: should be ue_count
		qdev->ue_count++;
	break;
case UE_NF:
	if (qdev->ce_count != UINT_MAX)   // BUG: should be ue_nf_count
		qdev->ue_nf_count++;
	break;
```

The fix correctly changes these to check the matching counter:

```c
case UE:
	if (qdev->ue_count != UINT_MAX)
		qdev->ue_count++;
	break;
case UE_NF:
	if (qdev->ue_nf_count != UINT_MAX)
		qdev->ue_nf_count++;
	break;
```

This is a textbook copy-paste error — the `CE` case was likely written first, and the guard condition was duplicated to `UE` and `UE_NF` without updating the variable name. The fix is minimal and obviously correct. The `Fixes:` tag is present and points to the commit that introduced the bug.

No concerns with this patch.

---
Generated by Claude Code Patch Reviewer