Message-ID: <sashiko-outbox-207338@kernel.org>
From: sashiko-bot@kernel.org
Subject: Re: [PATCH v2 10/28] drm/panthor: Skip devfreq when no OPP table is
 present
To: "Karunika Choo" <karunika.choo@arm.com>, dri-devel@lists.freedesktop.org
In-Reply-To: <20261110153907.3241978-11-karunika.choo@arm.com>
References: <20261110153907.3241978-1-karunika.choo@arm.com>
 <20261110153907.3241978-11-karunika.choo@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Nov 2026 16:03:59 +0000
Precedence: list
Reply-To: sashiko-reviews@lists.linux.dev
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/panthor: panthor_devfreq_init() leaves fast_rate at 0 on
  early return
--

commit f3bfa3d1d539b4b1bfaa2d96f490e98746dad160
Author: Karunika Choo <karunika.choo@arm.com>

drm/panthor: Skip devfreq when no OPP table is present

This commit skips devfreq initialization on Mali v15 AM systems when no OPP
table is present, guards the devfreq helpers against a NULL devfreq
instance, and falls back to clk_get_rate() when querying the current
frequency without devfreq.

> diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c b/drivers/gpu/drm/=
panthor/panthor_devfreq.c
> index 2249b41ca4afe..d1814b5197221 100644
> --- a/drivers/gpu/drm/panthor/panthor_devfreq.c
> +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c

[ ... ]

> @@ -164,6 +165,19 @@ int panthor_devfreq_init(struct panthor_device *ptde=
v)
>  	 */
>  	table =3D dev_pm_opp_get_opp_table(dev);
>  	if (IS_ERR_OR_NULL(table)) {
> +		/*
> +		 * On v15 GPUs, frequency scaling is handled outside of panthor
> +		 * by the AM_GOVERNOR block, so the GPU DT node may not provide
> +		 * an OPP table. In such cases, do not initialize devfreq for
> +		 * panthor.
> +		 */
> +		if (panthor_hw_is_gen5_am(ptdev->base.dev) &&
> +		    PTR_ERR(table) =3D=3D -ENODEV) {
> +			drmm_kfree(&ptdev->base, pdevfreq);
> +			ptdev->devfreq =3D NULL;
> +			return 0;
> +		}

[Severity: Medium]
As reported by Steven Price on RFC [1], does returning early here leave
ptdev->fast_rate at 0?  ptdev->fast_rate is only populated later in
panthor_devfreq_init() via dev_pm_opp_find_freq_floor(), and
panthor_gpu_show_fdinfo() unconditionally prints it:

drivers/gpu/drm/panthor/panthor_drv.c:panthor_gpu_show_fdinfo() {
	...
	drm_printf(p, "drm-maxfreq-panthor:\t%lu Hz\n", ptdev->fast_rate);
	drm_printf(p, "drm-curfreq-panthor:\t%lu Hz\n",
		   panthor_devfreq_get_freq(ptdev));
}

On v15 AM systems without an OPP table, reading fdinfo will report
"drm-maxfreq-panthor: 0 Hz" alongside a non-zero current frequency,
breaking userspace GPU utilization calculations that divide cycle counts
by drm-maxfreq-panthor.

[1] https://lore.kernel.org/r/dc038a81-3c59-49d5-ab8a-29202c7ce935@arm.com

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261110153907.3241=
978-1-karunika.choo@arm.com?part=3D10