From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: "Gupta, Anshuman" <anshuman.gupta@intel.com>,
"Nilawar, Badal" <badal.nilawar@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Jadav, Raag" <raag.jadav@intel.com>,
"Tauro, Riana" <riana.tauro@intel.com>,
"Koujalagi, Mallesh" <mallesh.koujalagi@intel.com>,
"Iddamsetty, Aravind" <aravind.iddamsetty@intel.com>,
"heikki.krogerus@linux.intel.com"
<heikki.krogerus@linux.intel.com>,
"Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
Subject: Re: [PATCH 2/2] drm/xe/cri: Expose device UUID through sysfs
Date: Tue, 8 Sep 2026 14:55:00 -0400 [thread overview]
Message-ID: <aqBaBBYpo1yoizXd@intel.com> (raw)
In-Reply-To: <b1ac6708-86e1-4c26-858b-5343b075bbf9@intel.com>
On Mon, Sep 07, 2026 at 05:48:12PM +0200, Michal Wajdeczko wrote:
>
>
> On 9/7/2026 2:04 PM, Gupta, Anshuman wrote:
> >
> >
> >> -----Original Message-----
> >> From: Wajdeczko, Michal <michal.wajdeczko@intel.com>
> >> Sent: Monday, September 7, 2026 5:25 PM
> >> To: Nilawar, Badal <badal.nilawar@intel.com>; intel-
> >> xe@lists.freedesktop.org; Vivi, Rodrigo <rodrigo.vivi@intel.com>
> >> Cc: Gupta, Anshuman <anshuman.gupta@intel.com>; Jadav, Raag
> >> <raag.jadav@intel.com>; Tauro, Riana <riana.tauro@intel.com>; Koujalagi,
> >> Mallesh <mallesh.koujalagi@intel.com>; Iddamsetty, Aravind
> >> <aravind.iddamsetty@intel.com>; heikki.krogerus@linux.intel.com;
> >> Ghimiray, Himal Prasad <himal.prasad.ghimiray@intel.com>
> >> Subject: Re: [PATCH 2/2] drm/xe/cri: Expose device UUID through sysfs
s/uuid/uid everywhere please. It is only a 64bit, not a 128.
> >>
> >>
> >>
> >> On 9/7/2026 11:13 AM, Nilawar, Badal wrote:
> >>>
> >>> On 04-09-2026 22:07, Michal Wajdeczko wrote:
> >>>>
> >>>> On 9/4/2026 6:06 PM, Badal Nilawar wrote:
> >>>>> Expose a read-only sysfs attribute, device_uuid, that reports the
> >>>>> GPU's unique hardware identifier.
> >>>>>
> >>>> Bspec: 53048,53049
> >>> Sure
> >>>>
> >>>>> Assisted-by: Claude:claude-opus-4.8
> >>>>> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com>
> >>>>> ---
> >>>>> .../ABI/testing/sysfs-driver-intel-xe-gpu | 10 ++++++
> >>>>> drivers/gpu/drm/xe/regs/xe_regs.h | 2 ++
> >>>>> drivers/gpu/drm/xe/xe_device.c | 3 ++
> >>>>> drivers/gpu/drm/xe/xe_device_sysfs.c | 36
> >>>>> +++++++++++++++++++
> >>>>> drivers/gpu/drm/xe/xe_device_types.h | 3 ++
> >>>>> 5 files changed, 54 insertions(+)
> >>>>> create mode 100644
> >>>>> Documentation/ABI/testing/sysfs-driver-intel-xe-gpu
> >>>>>
> >>>>> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-gpu
> >>>>> b/Documentation/ABI/testing/sysfs-driver-intel-xe-gpu
> >>>>> new file mode 100644
> >>>>> index 000000000000..1a4bdfbad8d7
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-gpu
> >>>>> @@ -0,0 +1,10 @@
> >>>>> +What: /sys/bus/pci/drivers/xe/.../device_uuid
> >>>>> +Date: September 2026
> >>>>> +KernelVersion: 7.4
> >>>>> +Contact: intel-xe@lists.freedesktop.org
> >>>>> +Description: RO. Unique 64-bit identifier of the device
> >>>>> +instance, read from
> >>>>> + the device's CRI_DEVICE_UUID register and printed as a
> >>>> hmm, maybe in the user facing documentation we should refer to this
> >>>> register as
> >>>>
> >>>> DEVICE_UUID(102008)
> >>>>
> >>>> instead of the meaningless macro name?
> >>> I will drop "read from ..." statement.
> >>>>
> >>>>> + zero-padded 16-digit hexadecimal string.
> >>>> if this is UUID, shouldn't we print it in UUID format? see %pU
> >>> I this is not UUID, i will rename the node as device_uid.
> >>>>
> >>>>> +
> >>>>> + This sysfs file is present only on Intel Xe platforms that
> >>>>> + provide a device UUID. It is available to all users.
> >>>>> diff --git a/drivers/gpu/drm/xe/regs/xe_regs.h
> >>>>> b/drivers/gpu/drm/xe/regs/xe_regs.h
> >>>>> index ef4746b7b5d3..68226fe0b659 100644
> >>>>> --- a/drivers/gpu/drm/xe/regs/xe_regs.h
> >>>>> +++ b/drivers/gpu/drm/xe/regs/xe_regs.h
> >>>>> @@ -30,6 +30,8 @@
> >>>>> #define XEHP_MTCFG_ADDR XE_REG(0x101800)
> >>>>> #define TILE_COUNT REG_GENMASK(15, 8)
> >>>>> +#define CRI_DEVICE_UUID XE_REG(0x102008)
> >>>>> +
> >>>>> #define GGC XE_REG(0x108040)
> >>>>> #define GMS_MASK REG_GENMASK(15, 8)
> >>>>> #define GGMS_MASK REG_GENMASK(7, 6) diff --git
> >>>>> a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> >>>>> index 8583b2e9ecf4..e8db8871990b 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);
> >>>>> +
> >>>>> /*
> >>>>> * Check for pcode uncore_init status to confirm if the SoC
> >>>>> * initialization is complete. Until done, any MMIO or lmem
> >>>>> access from diff --git a/drivers/gpu/drm/xe/xe_device_sysfs.c
> >>>>> b/drivers/gpu/drm/xe/xe_device_sysfs.c
> >>>>> index a73e0e957cb0..a4d326159dce 100644
> >>>>> --- a/drivers/gpu/drm/xe/xe_device_sysfs.c
> >>>>> +++ b/drivers/gpu/drm/xe/xe_device_sysfs.c
> >>>>> @@ -8,6 +8,7 @@
> >>>>> #include <linux/pci.h>
> >>>>> #include <linux/sysfs.h>
> >>>>> +#include "regs/xe_regs.h"
> >>>>> #include "xe_device.h"
> >>>>> #include "xe_device_sysfs.h"
> >>>>> #include "xe_mmio.h"
> >>>>> @@ -264,6 +265,35 @@ static const struct attribute_group
> >>>>> auto_link_downgrade_attr_group = {
> >>>>> .attrs = auto_link_downgrade_attrs,
> >>>>> };
> >>>>> +/**
> >>>>> + * DOC: device_uuid
> >>>> do we need this?
> >>>> you already described that in Documentation/ABI
> >>> I think I will drop the Documentation/ABI and keep DOC: section.
> >>
> >> hmm, but all other sysfs entries are defined in Documentation/ABI (which
> >> IMO is the correct place, not a local DOC section)
> > Is there a way to link the Documentation/ABI doc with drm/Xe Doc, in case local doc is not preferred.
> > https://docs.kernel.org/gpu/xe/index.html
> > As this is Xe specific sysfs , AFAIU there should be some way from Xe Kernel Doc to refer this sysfs ?
>
> it should be sufficient to use:
>
> "See Documentation/ABI/testing/sysfs-driver-intel-xe-gpu
> "for a complete description of the attributes.
>
> see https://elixir.bootlin.com/linux/v7.2.2/source/Documentation/hwmon/sysfs-interface.rst#L92
> and resulting https://docs.kernel.org/hwmon/sysfs-interface.html#attribute-access
yes, please, let's simplify this as much as we can.
>
> > Thanks,
> > Anshuman
> >>
> >>
> >>>>
> >>>>> + *
> >>>>> + * Each Xe device exposes a 64-bit UUID that uniquely identifies the SoC.
> >>>>> + * The value is read from the CRI_DEVICE_UUID register and can be
> >>>>> + * read back through the ``device_uuid`` sysfs entry.
> >>>>> + *
> >>>>> + * $ cat /sys/bus/pci/devices/<bdf>/device_uuid
> >>>>> + */
> >>>>> +
> >>>>> +static ssize_t
> >>>>> +device_uuid_show(struct device *dev, struct device_attribute *attr,
> >>>>> +char *buf) {
> >>>>> + struct pci_dev *pdev = to_pci_dev(dev);
> >>>>> + struct xe_device *xe = pdev_to_xe_device(pdev);
> >>>>> +
> >>>>> + return sysfs_emit(buf, "%016llx\n", xe->device_uuid);
> >>>> %pU ?
> >>> Not needed.
> >>>>
> >>>>> +}
> >>>>> +static DEVICE_ATTR_RO(device_uuid);
> >>>>> +
> >>>>> +static struct attribute *device_uuid_attrs[] = {
> >>>>> + &dev_attr_device_uuid.attr,
> >>>>> + NULL
> >>>>> +};
> >>>>> +
> >>>>> +static const struct attribute_group device_uuid_attr_group = {
> >>>>> + .attrs = device_uuid_attrs,
> >>>>> +};
> >>>>> +
> >>>>> int xe_device_sysfs_init(struct xe_device *xe)
> >>>>> {
> >>>>> struct device *dev = xe->drm.dev; @@ -285,5 +315,11 @@ int
> >>>>> xe_device_sysfs_init(struct xe_device *xe)
> >>>>> return ret;
> >>>>> }
> >>>>> + if (xe->info.platform == XE_CRESCENTISLAND) {
> >>>> use .is_visible instead
> >>>
> >>> Will add has flag.
> >>
> >> to be clear: my point was to move this check to the
> >>
> >> attribute_group.is_visible
> >>
> >> and I don't care whether it will use .has_uid or .platform field
> >>
> >>
> >>>
> >>> Thanks,
> >>> Badal
> >>>
> >>>>
> >>>>> + ret = devm_device_add_group(dev, &device_uuid_attr_group);
> >>>>> + if (ret)
> >>>>> + return ret;
> >>>>> + }
> >>>>> +
> >>>>> return 0;
> >>>>> }
> >>>>> diff --git a/drivers/gpu/drm/xe/xe_device_types.h
> >>>>> b/drivers/gpu/drm/xe/xe_device_types.h
> >>>>> index 180d450a6deb..6fdd16eac906 100644
> >>>>> --- a/drivers/gpu/drm/xe/xe_device_types.h
> >>>>> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> >>>>> @@ -257,6 +257,9 @@ struct xe_device {
> >>>>> bool oob_initialized;
> >>>>> } wa_active;
> >>>>> + /** @device_uuid: unique 64-bit identifier read from
> >>>>> CRI_DEVICE_UUID */
> >>>>> + u64 device_uuid;
> >>>>> +
> >>>>> /** @survivability: survivability information for device */
> >>>>> struct xe_survivability survivability;
> >>>>>
> >
>
next prev parent reply other threads:[~2026-09-08 18:55 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
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 [this message]
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=aqBaBBYpo1yoizXd@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@intel.com \
--cc=badal.nilawar@intel.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
/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.