From: sashiko-bot@kernel.org
To: "Badal Nilawar" <badal.nilawar@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/xe/cri: Expose device UUID through sysfs
Date: Fri, 04 Sep 2026 15:57:37 +0000 [thread overview]
Message-ID: <20260904155738.434481F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904160608.2004174-6-badal.nilawar@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing SR-IOV VF guard for CRI_DEVICE_UUID MMIO read and sysfs registration.
- [High] MMIO read of CRI_DEVICE_UUID is performed before pcode uncore_init completion.
--
commit 23a0b7f2a1ab91a9391ba06e886cb50c9626ce7d
Author: Badal Nilawar <badal.nilawar@intel.com>
drm/xe/cri: Expose device UUID through sysfs
This commit exposes a read-only sysfs attribute to report the GPU's unique
hardware identifier.
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 8583b2e9ecf4c..e8db8871990b2 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -801,6 +801,9 @@ int xe_device_probe_early(struct xe_device *xe)
> if (IS_SRIOV_VF(xe))
> vf_update_device_info(xe);
>
> + if (xe->info.platform == XE_CRESCENTISLAND)
> + xe->device_uuid = xe_mmio_read64_2x32(xe_root_tile_mmio(xe), CRI_DEVICE_UUID);
> +
[Severity: High]
Is it safe to read this MMIO register from a Virtual Function (VF) context?
If this register is PF-only, accessing it from a VF might cause MMIO timeouts
or hardware errors. Should this be guarded with !IS_SRIOV_VF(xe)?
[Severity: High]
Does this MMIO read happen too early?
The comment right below this read states that "any MMIO or lmem access from
the driver will be blocked" until pcode uncore_init is done in
xe_pcode_probe_early(). If we read the register before this initialization
completes, will it result in a bus hang or reading invalid data?
> /*
> * Check for pcode uncore_init status to confirm if the SoC
> * initialization is complete. Until done, any MMIO or lmem access from
> * the driver will be blocked
> */
> err = xe_pcode_probe_early(xe);
[ ... ]
> diff --git a/drivers/gpu/drm/xe/xe_device_sysfs.c b/drivers/gpu/drm/xe/xe_device_sysfs.c
> index a73e0e957cb0b..a4d326159dce3 100644
> --- a/drivers/gpu/drm/xe/xe_device_sysfs.c
> +++ b/drivers/gpu/drm/xe/xe_device_sysfs.c
> @@ -285,5 +315,11 @@ int xe_device_sysfs_init(struct xe_device *xe)
> return ret;
> }
>
> + if (xe->info.platform == XE_CRESCENTISLAND) {
> + ret = devm_device_add_group(dev, &device_uuid_attr_group);
> + if (ret)
> + return ret;
> + }
> +
[Severity: High]
If the device UUID cannot be read on VFs, should we prevent registering the
sysfs attribute for VFs as well?
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904160608.2004174-4-badal.nilawar@intel.com?part=2
next prev parent reply other threads:[~2026-09-04 15:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 16:06 [PATCH 0/2] Expose device sysfs for AMC and GPU UUID Badal Nilawar
2026-09-04 15:56 ` ✗ CI.checkpatch: warning for " Patchwork
2026-09-04 15:58 ` ✓ CI.KUnit: success " Patchwork
2026-09-04 16:06 ` [PATCH 1/2] drm/xe/i2c: Expose AMC Alert reason sysfs Badal Nilawar
2026-09-08 18:52 ` Rodrigo Vivi
2026-09-09 14:27 ` Nilawar, Badal
2026-09-09 15:32 ` Nilawar, Badal
2026-09-04 16:06 ` [PATCH 2/2] drm/xe/cri: Expose device UUID through sysfs Badal Nilawar
2026-09-04 15:57 ` sashiko-bot [this message]
2026-09-04 16:02 ` Gupta, Anshuman
2026-09-04 16:37 ` Michal Wajdeczko
2026-09-07 9:13 ` Nilawar, Badal
2026-09-07 11:55 ` Michal Wajdeczko
2026-09-07 12:04 ` Gupta, Anshuman
2026-09-07 15:48 ` Michal Wajdeczko
2026-09-08 18:55 ` Rodrigo Vivi
2026-09-10 6:31 ` Nilawar, Badal
2026-09-07 5:02 ` Joonas Lahtinen
2026-09-07 8:16 ` Nilawar, Badal
2026-09-04 16:48 ` ✓ Xe.CI.BAT: success for Expose device sysfs for AMC and GPU UUID Patchwork
2026-09-05 0:54 ` ✓ Xe.CI.FULL: " Patchwork
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=20260904155738.434481F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.