Re: [PATCH v2] drm/xe/hwmon: Enable package and vram temperatures for CRI

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Potential division by zero in `get_mc_temp` when the thermal sensor count is 3.
--

--- Patch [1]: [PATCH v2] drm/xe/hwmon: Enable package and vram temperatures for CRI ---
commit 7fa6b15888cc9f0808566087b3307d62fbda4703
Author: Karthik Poosa <[email protected]>

drm/xe/hwmon: Enable package and vram temperatures for CRI

This commit enables package and vram temperatures support from hwmon on the
CRI platform. It updates the hwmon register mapping to use the same MMIO
offsets as BMG.

> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c b/drivers/gpu/drm/xe/xe_hwmon.c
> index de3f2aeffc3fb..30059f1de5a82 100644
> --- a/drivers/gpu/drm/xe/xe_hwmon.c
> +++ b/drivers/gpu/drm/xe/xe_hwmon.c

[ ... ]

>  static int get_mc_temp(struct xe_hwmon *hwmon, long *val)
>  {
>  	struct xe_tile *root_tile = xe_device_get_root_tile(hwmon->xe);

[ ... ]

>  	for (i = TEMP_INDEX_MCTRL; i < hwmon->temp.count - 1; i++)
>  		average += hwmon->temp.value[i];
>  
>  	average /= (hwmon->temp.count - TEMP_INDEX_MCTRL - 1);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for a division
by zero to occur here in get_mc_temp()?

If the hardware or firmware provides a thermal sensor count of 3, and
TEMP_INDEX_MCTRL is 2, the denominator evaluates to 0.

Since the sysfs file for CHANNEL_MCTRL is visible as long as count > 0,
could a local unprivileged user reading the sysfs attribute trigger a kernel
panic if this condition is met?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1