+		for (i = 0; i < num_headers; i++) {
+			u32 num_logs = min_t(u32, hdrs[i].counter, XE_RAS_NUM_COUNTERS);
[Severity: Medium]
Does capping `num_logs` to `XE_RAS_NUM_COUNTERS` (16) cause desynchronization
when parsing the raw log stream? If the hardware actually embedded more than
16 logs for a specific header, limiting `num_logs` to 16 means `log_offset`
will only advance by 16. Won't the remaining logs then be incorrectly parsed
as belonging to the next aggregate header in the stream?

hdrs[i].counter may exceed XE_RAS_NUM_COUNTERS, but the info queue contains at most XE_RAS_NUM_COUNTERS log entries. 

The cap reflects the amount of log data actually present in the buffer, so log_offset remains synchronized with the parsed stream.

Thanks,
Badal