Re: [PATCH v15 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: restoring PCI_COMMAND enables memory decode with 0-initialized BARs
--

commit 760a69f51b8830cd55e316a784f0c3e65a321b72
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

This commit introduces a device-specific hardware reset mechanism for Qualcomm 
SDX62/SDX65 modems. It uses a sequence of writes to BAR0 MHI SoC reset 
registers to properly initialize the devices for VFIO passthrough.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index de9bbccda21fd..e72af7d2c7755 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
[ ... ]
> @@ -4230,6 +4230,45 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
[ ... ]
> +static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
> +{
> +	void __iomem *bar;
> +	u16 cmd;
> +
> +	if (probe)
> +		return 0;
> +
> +	if (pdev->current_state != PCI_D0)
> +		return -EINVAL;
> +
> +	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> +	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
> +
> +	bar = pci_iomap(pdev, 0, 0);
> +	if (!bar) {
> +		pci_write_config_word(pdev, PCI_COMMAND, cmd);
> +		return -ENODEV;
> +	}
> +
> +	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
> +	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
> +
> +	/* Be sure device reset has been executed */
> +	msleep(2000);
> +
> +	pci_iounmap(pdev, bar);
> +	pci_write_config_word(pdev, PCI_COMMAND, cmd);

[Severity: High]
Could restoring PCI_COMMAND here cause a system address conflict?

If the saved cmd originally had the PCI_COMMAND_MEMORY bit set (for example,
when called from a path like Xen PCIBACK's pcistub_reset_device_state),
writing it back immediately enables memory decode. Because the hardware reset
has just occurred, the device's BARs will have been cleared to 0.

Does this create a risk of silent memory corruption by allowing the device to
claim physical address 0 before the PCI core has a chance to restore the BARs
properly in pci_restore_config_space()?

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