From: sashiko-bot@kernel.org
To: "Karunika Choo" <karunika.choo@arm.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1 04/27] drm/panthor: Add 64-bit GPU_ID decoding for v15 GPUs
Date: Tue, 22 Sep 2026 21:01:17 +0000 [thread overview]
Message-ID: <20260922210117.CEC081F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260922204535.2850094-5-karunika.choo@arm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] drm/panthor: missing driver version bump for UAPI addition
- [Low] drm/tyr: build failure due to exhaustive struct initialization
--
commit 543a83f06edb5e6a777b3ef1eefcac27b352d2c8
Author: Karunika Choo <karunika.choo@arm.com>
drm/panthor: Add 64-bit GPU_ID decoding for v15 GPUs
Mali v15 exposes a 64-bit GPU_ID register with a different field layout
from earlier GPUs. This patch adds the register definitions, decoding helpers,
and populates the new uAPI gpu_wide_id field.
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index a2ff0f4ec6915..843a0b40e1d36 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
[ ... ]
> @@ -376,6 +376,19 @@ struct drm_panthor_gpu_info {
>
> /** @gpu_features: Bitmask describing supported GPU-wide features */
> __u64 gpu_features;
> +
> + /**
> + * @gpu_wide_id: 64-bit GPU ID for v15 and later GPUs. @gpu_id is 0 when
> + * this is populated.
> + */
> + __u64 gpu_wide_id;
[Severity: Medium]
Does the addition of this new UAPI field require a driver version bump?
The UAPI documentation for Panthor mandates that each new flag or field
addition must come with a driver version update, so the userspace driver
doesn't have to rely on trial and error to know which flags are supported.
However, the driver minor version in panthor_drm_driver within
drivers/gpu/drm/panthor/panthor_drv.c remains at 9:
.major = 1,
.minor = 9,
Will userspace be forced to use trial and error to determine support for
this field without an incremented minor version?
[Severity: Low]
Will this UAPI structure modification cause a build failure in the Rust tyr
driver?
The Rust driver utilizes this structure via bindgen and initializes it
exhaustively in GpuInfo::new() within drivers/gpu/drm/tyr/gpu.rs:
Self(uapi::drm_panthor_gpu_info {
gpu_id: io.read(GPU_ID).into_raw(),
gpu_rev: io.read(REVIDR).into_raw(),
Because the exhaustive initializer lacks the new gpu_wide_id field, the
Rust compiler will fail with a missing field error. Has this compile-time
regression been addressed?
> +#define DRM_PANTHOR_WIDE_ARCH_MAJOR(x) (((x) >> 56) & 0xff)
> +#define DRM_PANTHOR_WIDE_ARCH_MINOR(x) (((x) >> 48) & 0xff)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260922204535.2850094-1-karunika.choo@arm.com?part=4
next prev parent reply other threads:[~2026-09-22 21:01 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 20:44 [PATCH v1 00/27] drm/panthor: Add Mali v15 virtualization support Karunika Choo
2026-09-22 20:44 ` [PATCH v1 01/27] drm/panthor: Ignore -EOPNOTSUPP for shader-present nvmem lookup Karunika Choo
2026-09-22 20:44 ` [PATCH v1 02/27] drm/panthor: Move register access helpers out of panthor_device.h Karunika Choo
2026-09-22 20:54 ` sashiko-bot
2026-09-22 20:44 ` [PATCH v1 03/27] drm/panthor: Parse and store GPU_ID fields Karunika Choo
2026-09-22 20:56 ` sashiko-bot
2026-09-22 20:44 ` [PATCH v1 04/27] drm/panthor: Add 64-bit GPU_ID decoding for v15 GPUs Karunika Choo
2026-09-22 21:01 ` sashiko-bot [this message]
2026-09-22 23:23 ` Deborah Brouwer
2026-09-22 20:44 ` [PATCH v1 05/27] drm/panthor: Move register base offsets to the HW description Karunika Choo
2026-09-22 20:45 ` [PATCH v1 06/27] drm/panthor: Derive MMU AS register addresses from base and stride Karunika Choo
2026-09-22 21:00 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 07/27] dt-bindings: gpu: mali-valhall-csf: Add Mali Gen5 AM compatible Karunika Choo
2026-09-28 10:02 ` Krzysztof Kozlowski
2026-09-22 20:45 ` [PATCH v1 08/27] drm/panthor: Add Mali v15 hardware support Karunika Choo
2026-09-22 20:58 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 09/27] drm/panthor: Skip devfreq when no OPP table is present Karunika Choo
2026-09-22 20:45 ` [PATCH v1 10/27] dt-bindings: gpu: panthor: Document panthor-system bindings Karunika Choo
2026-09-22 20:56 ` sashiko-bot
2026-09-28 10:05 ` Krzysztof Kozlowski
2026-09-22 20:45 ` [PATCH v1 11/27] drm/panthor: Add AM_SYSTEM platform driver Karunika Choo
2026-09-22 20:59 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 12/27] dt-bindings: gpu: panthor: Document panthor-arbitration bindings Karunika Choo
2026-09-22 20:59 ` sashiko-bot
2026-09-28 10:06 ` Krzysztof Kozlowski
2026-09-22 20:45 ` [PATCH v1 13/27] drm/panthor: Add AM_PARTITION_CONTROL support Karunika Choo
2026-09-22 20:57 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 14/27] drm/panthor: Add AM message helpers Karunika Choo
2026-09-22 20:58 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 15/27] drm/panthor: Add AM_RESOURCE_GROUP support Karunika Choo
2026-09-22 20:56 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 16/27] drm/panthor: Add arbitration scheduler Karunika Choo
2026-09-22 21:00 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 17/27] drm/panthor: Route arbitration events Karunika Choo
2026-09-22 21:04 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 18/27] dt-bindings: gpu: panthor: Document AW assignment DT property Karunika Choo
2026-09-22 20:57 ` sashiko-bot
2026-09-28 10:06 ` Krzysztof Kozlowski
2026-09-22 20:45 ` [PATCH v1 19/27] drm/panthor: Add AW assignment tracking Karunika Choo
2026-09-22 20:45 ` [PATCH v1 20/27] drm/panthor: Handle partition control INVALID_COMMAND interrupt Karunika Choo
2026-09-22 21:04 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 21/27] drm/panthor: Request AW to yield GPU access on idle Karunika Choo
2026-09-22 21:07 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 22/27] drm/panthor: Add access-window support Karunika Choo
2026-09-22 21:05 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 23/27] drm/panthor: Synchronize HW component PM transitions Karunika Choo
2026-09-22 20:45 ` [PATCH v1 24/27] drm/panthor: Route HW component PM through access windows Karunika Choo
2026-09-22 21:06 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 25/27] drm/panthor: Tolerate access-window loss during HW waits Karunika Choo
2026-09-22 21:14 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 26/27] drm/panthor: Prevent missed post-yield cleanup due to reset Karunika Choo
2026-09-22 21:12 ` sashiko-bot
2026-09-22 20:45 ` [PATCH v1 27/27] drm/panthor: Release GPU access immediately for out-of-band grants Karunika Choo
2026-09-22 21:06 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260922210117.CEC081F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=karunika.choo@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox