Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/xe/configfs: Allow configurations only for Intel VGA devices
Date: Thu, 17 Jul 2025 22:51:36 +0200	[thread overview]
Message-ID: <828bb2f9-e486-48bb-9d88-75c54a370640@intel.com> (raw)
In-Reply-To: <4giwyvxxjwwopctdrugqgnwjdytushpvumxd7lbmzobg2bamax@nuegb34lc4qi>



On 17.07.2025 21:52, Lucas De Marchi wrote:
> On Thu, Jul 17, 2025 at 08:48:24PM +0200, Michal Wajdeczko wrote:
>> The Xe driver supports only Intel GPUs devices that all are PCI
>> VGA class devices. Reject creation of configuration directories
>> for PCI device addresses that are not Intel or VGA.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_configfs.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_configfs.c b/drivers/gpu/drm/xe/
>> xe_configfs.c
>> index 00bb4e412c12..1df8cce78f13 100644
>> --- a/drivers/gpu/drm/xe/xe_configfs.c
>> +++ b/drivers/gpu/drm/xe/xe_configfs.c
>> @@ -260,6 +260,7 @@ static struct config_group
>> *xe_config_make_device_group(struct config_group *gro
>>     struct xe_config_device *dev;
>>     struct pci_dev *pdev;
>>     char canonical[16];
>> +    bool match;
>>     int ret;
>>
>>     ret = sscanf(name, "%x:%x:%x.%d", &domain, &bus, &slot, &function);
>> @@ -275,8 +276,14 @@ static struct config_group
>> *xe_config_make_device_group(struct config_group *gro
>>     pdev = pci_get_domain_bus_and_slot(domain, bus, PCI_DEVFN(slot,
>> function));
>>     if (!pdev)
>>         return ERR_PTR(-ENODEV);
>> +
>> +    match = pci_is_vga(pdev) && pdev->vendor == PCI_VENDOR_ID_INTEL;
> 
> although not officially supported by xe, we had devices in the past with
> class 0x0380 and (I think) 0x302.

I can look directly at pdev->class to check for all legacy classes

> 
> is the goal here to error early on typos that cause the config to not
> "stick" and now error/warning to the user? 

they would stick, but what's the point to allow user adding config for
the PCI devices that we will never be able to use?

IMO since we error early if given PCI device address is not present on
current system, we should also try to error early if someone enters data
using PCI address of not our device

> Maybe we should rather have a
> positive indication during bind that the user can grep for in the log?

that could be added independently as a confirmation that driver noticed
specific configuration was prepared for given device:

 [ ] xe 0000:00:02.0: [drm] found custom settings in configfs!

I guess individual params, if different than default, should be logged
on the go, like something like this one from engines_allowed:

 [ ] xe 0000:00:02.0: [drm] GT1: vcs0 disabled via configfs

> 
> Lucas De Marchi
> 
>> +
>>     pci_dev_put(pdev);
>>
>> +    if (!match)
>> +        return ERR_PTR(-ENODEV);
>> +
>>     dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>>     if (!dev)
>>         return ERR_PTR(-ENOMEM);
>> -- 
>> 2.47.1
>>


  reply	other threads:[~2025-07-17 20:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-17 18:48 [PATCH 0/5] Updates for drm/xe/configfs Michal Wajdeczko
2025-07-17 18:48 ` [PATCH 1/5] drm/xe/configfs: Fix pci_dev reference leak Michal Wajdeczko
2025-07-17 19:35   ` Lucas De Marchi
2025-07-17 21:16   ` Cavitt, Jonathan
2025-07-18  8:58     ` Michal Wajdeczko
2025-07-17 18:48 ` [PATCH 2/5] drm/xe/configfs: Enforce canonical device names Michal Wajdeczko
2025-07-17 19:43   ` Lucas De Marchi
2025-07-17 20:27     ` Michal Wajdeczko
2025-07-17 21:17   ` Cavitt, Jonathan
2025-07-18  9:06     ` Michal Wajdeczko
2025-07-18 14:16       ` Cavitt, Jonathan
2025-07-18 14:05   ` [PATCH v2 " Michal Wajdeczko
2025-07-18 20:52     ` Lucas De Marchi
2025-07-17 18:48 ` [PATCH 3/5] drm/xe/configfs: Use pci_name() for lookup Michal Wajdeczko
2025-07-17 19:44   ` Lucas De Marchi
2025-07-17 21:18   ` Cavitt, Jonathan
2025-07-18  9:23     ` Michal Wajdeczko
2025-07-17 18:48 ` [PATCH 4/5] drm/xe/configfs: Allow configurations only for Intel VGA devices Michal Wajdeczko
2025-07-17 19:52   ` Lucas De Marchi
2025-07-17 20:51     ` Michal Wajdeczko [this message]
2025-07-18 21:02       ` Lucas De Marchi
2025-07-17 21:19   ` Cavitt, Jonathan
2025-07-18  9:29     ` Michal Wajdeczko
2025-07-18 14:27       ` Cavitt, Jonathan
2025-07-18 14:33         ` Michal Wajdeczko
2025-07-18 17:28           ` Cavitt, Jonathan
2025-07-18 14:17   ` [PATCH v2 " Michal Wajdeczko
2025-07-17 18:48 ` [PATCH 5/5] drm/xe/configfs: Allow adding configurations for future VFs Michal Wajdeczko
2025-07-17 21:19   ` Cavitt, Jonathan
2025-07-17 19:06 ` ✓ CI.KUnit: success for Updates for drm/xe/configfs Patchwork
2025-07-17 20:13 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-18 14:23 ` ✓ CI.KUnit: success for Updates for drm/xe/configfs (rev3) Patchwork
2025-07-18 15:15 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-19  7:47 ` ✗ Xe.CI.Full: failure for Updates for drm/xe/configfs Patchwork
2025-07-21 10:53 ` ✗ Xe.CI.Full: failure for Updates for drm/xe/configfs (rev3) 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=828bb2f9-e486-48bb-9d88-75c54a370640@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@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