Re: [PATCH v2 05/11] drm/xe/cper: Prepare Intel CPER error info from info queue

["Nilawar, Badal" <badal.nilawar@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]


On 25-08-2026 23:24, sashiko-bot@kernel.org wrote:
>> +		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

[-- Attachment #2: Type: text/html, Size: 1638 bytes --]