Re: [PATCH v3 12/12] drm/xe/cper: Emit cper record to trace buf

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Incorrect format specifier `%pU` is used to format `guid_t` variables, which will print them with the wrong byte order.
--

commit d2b3c6858920421ba035f9890d1e0ee71777bc35
Author: Badal Nilawar <badal.nilawar@intel.com>

drm/xe/cper: Emit cper record to trace buf

This commit emits CPER records to the trace buffer by adding a new
xe_error_cper tracepoint and calling it during xe_cper_record_emit().

> diff --git a/drivers/gpu/drm/xe/xe_trace_cper.h b/drivers/gpu/drm/xe/xe_trace_cper.h
> new file mode 100644
> index 0000000000000..6d2dbf5048884
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_trace_cper.h
[ ... ]
> +TRACE_EVENT(xe_error_cper,
> +	TP_PROTO(struct xe_device *xe,
> +	    const guid_t *platform_id, const guid_t *fru_id,
> +	    const u8 severity,
> +	    const struct xe_cper_sec_intel_err_hdr *ihdr,
> +	    u32 cper_len, const u8 *cper),
> +	TP_ARGS(xe, platform_id, fru_id, severity, ihdr, cper_len, cper),
[ ... ]
> +	TP_printk("dev=%s severity=%d platform_id=%pU fru_id=%pU "
> +		"intel_err_hdr_raw=%s cper_len=%u cper_raw=%s",

[Severity: Low]
Will this print the GUIDs in the wrong byte order? The platform_id and fru_id
fields are populated from guid_t structures, which represent little-endian
GUIDs. The %pU format specifier expects a big-endian uuid_t, so it will output
the first three segments in reverse byte order.

Should this use %pUl instead to correctly format the little-endian guid_t?

> +		__get_str(dev), __entry->sev,
> +		__entry->platform_id, __entry->fru_id,
> +		__print_hex(__entry->ihdr_raw,
> +		    sizeof(struct xe_cper_sec_intel_err_hdr)),
> +		__entry->cper_len,
> +		__print_hex(__get_dynamic_array(cper),
> +		    __entry->cper_len))
> +);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906172604.2215987-14-badal.nilawar@intel.com?part=12