Re: [PATCH v2] PCI: Force PM reset for Qualcomm devices with NoSoftRst+

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The local variable `csr` is left uninitialized and later written to the PCI Power Management Control register when the `PCI_DEV_FLAGS_FORCE_PM_RESET` flag is set.
--

commit 1f91cbd53469950e5e046d032ea4bd761ddec438
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Force PM reset for Qualcomm devices with NoSoftRst+

This commit adds a new PCI_DEV_FLAGS_FORCE_PM_RESET flag to bypass the
PCI_PM_CTRL_NO_SOFT_RESET check during PM reset, applying it as a quirk
to several Qualcomm devices. This allows devices without FLR that falsely
advertise NoSoftRst+ to be properly reset, which is necessary for VFIO
passthrough re-assignment.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8f7cfcc000901..e0b32eccfcf42 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4460,9 +4464,11 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
>  	if (!dev->pm_cap || dev->dev_flags & PCI_DEV_FLAGS_NO_PM_RESET)
>  		return -ENOTTY;
>  
> -	pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &csr);
> -	if (csr & PCI_PM_CTRL_NO_SOFT_RESET)
> -		return -ENOTTY;
> +	if (!(dev->dev_flags & PCI_DEV_FLAGS_FORCE_PM_RESET)) {
> +		pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &csr);
> +		if (csr & PCI_PM_CTRL_NO_SOFT_RESET)
> +			return -ENOTTY;
> +	}
>  
>  	if (probe)
>  		return 0;

If the PCI_DEV_FLAGS_FORCE_PM_RESET flag is set, does this leave the local
variable csr uninitialized?

Looking at the rest of pci_pm_reset():

drivers/pci/pci.c:pci_pm_reset() {
	...
	csr &= ~PCI_PM_CTRL_STATE_MASK;
	csr |= PCI_D3hot;
	pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, csr);
	...
}

Writing uninitialized stack memory back to the PM Control/Status Register
could corrupt hardware state like PME Enable and Data Scale, or inadvertently
clear Write-1-to-Clear bits like PME Status.

Could this cause unpredictable device behavior or lockups?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260508145153.717641-2-jtornosm@redhat.com?part=1