From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>, <rodrigo.vivi@intel.com>
Cc: <anshuman.gupta@intel.com>, <raag.jadav@intel.com>,
<riana.tauro@intel.com>, <mallesh.koujalagi@intel.com>,
<aravind.iddamsetty@intel.com>, <heikki.krogerus@linux.intel.com>,
<himal.prasad.ghimiray@intel.com>
Subject: Re: [PATCH 2/2] drm/xe/cri: Expose device UUID through sysfs
Date: Thu, 10 Sep 2026 12:01:30 +0530 [thread overview]
Message-ID: <be45d8ff-b084-4d15-bdbd-bc8087860722@intel.com> (raw)
In-Reply-To: <01acf34a-3231-45c7-b8ce-e70ead34a44d@intel.com>
On 07-09-2026 17:25, Michal Wajdeczko wrote:
>
> 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)
>
>
>>>> + *
>>>> + * 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
I don't think is_visible() is necessary here. It makes sense for cases
such as late_bind_attr_is_visible(), where attribute visibility is
determined dynamically.
In this case, support for the attribute is known before the sysfs
entries are created, so I'd prefer to keep the current approach.
if (xe->has_uid && !IS_SRIOV_VF(xe))
ret = devm_device_add_group(dev, &device_uid_attr_group);
if (ret)
return ret;
Thanks,
Badal
>
>> 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-10 6:31 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
2026-09-10 6:31 ` Nilawar, Badal [this message]
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=be45d8ff-b084-4d15-bdbd-bc8087860722@intel.com \
--to=badal.nilawar@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@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 \
--cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox