Re: [PATCH v6 1/7] drm/xe/pm: initialize the device's system wakeup capabilities

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Using devm_device_init_wakeup() on a PCI device corrupts bus-managed can_wakeup state on unbind.
- [Medium] Unconditional execution of devm_device_init_wakeup() forcefully overrides PCI PME capabilities and violates SR-IOV VF constraints.
--

commit df4a3e5da10819a464844de67d48ba7d13070965
Author: Vinod Govindapillai <vinod.govindapillai@intel.com>

drm/xe/pm: initialize the device's system wakeup capabilities

This commit enables the device as a wakeup device so display hotplugs can
generate PM PME events. This enables invoking the PM runtime resume routine
for NVL+ XE devices.

> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 5f2a0b19839d1..32e10e1a26eff 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -1200,6 +1200,10 @@ static int xe_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>  
>  	pci_set_master(pdev);
>  
> +	err = devm_device_init_wakeup(&pdev->dev);

[Severity: High]
Does calling devm_device_init_wakeup() on a PCI device corrupt the
bus-managed can_wakeup state on unbind?

When the driver is unbound, the devres cleanup triggers
device_disable_wakeup(), which explicitly calls
device_set_wakeup_capable(dev, false). This causes the device to permanently
lose its can_wakeup capability in the driver model, breaking PME capabilities
and userspace sysfs interfaces after a driver unbind/rebind cycle.

Should the driver use device_wakeup_enable() to toggle only the
should_wakeup state, rather than overriding the bus-owned capability flag set
during bus enumeration?

[Severity: Medium]
Does this unconditional execution of devm_device_init_wakeup() forcefully
override PCI PME capabilities and violate SR-IOV VF constraints?

The driver forcefully sets can_wakeup = true on devices that physically do
not support PME (like Virtual Functions or older hardware), leading to
invalid sysfs attributes and potential power management misbehavior.

This happens before xe_probe_info_early() determines the hardware generation
and without checking IS_SRIOV_VF() to ensure this PF-only power management
configuration is not executed on VFs. Should this initialization be
conditionally guarded based on the hardware capabilities and virtual function
constraints?

> +	if (err)
> +		return err;
> +
>  	err = xe_probe_info_early(xe, desc, &probed_info);
>  	if (err)
>  		return err;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914194737.272679-1-vinod.govindapillai@intel.com?part=1