Re: [PATCH v14 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: reset_qualcomm_modem re-enables memory decoding with zeroed BARs
--

commit 697e75cacc91e92df3d44b2fa95b07329f110e59
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

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

Qualcomm SDX62/SDX65 5G modems lack working reset methods for VFIO
passthrough. This commit adds a device-specific reset method for them using
MHI SoC reset via BAR0. The reset method writes to a hardware reset
register and waits for completion.

> 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

[ ... ]

> +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]
Does this unsafely enable memory decoding on a hardware-reset device with
zeroed BARs?

If the caller did not explicitly clear PCI_COMMAND_MEMORY before the reset,
cmd will have PCI_COMMAND_MEMORY set.

The hardware reset zeroes the device's PCI configuration space, including all
BARs. Restoring cmd with PCI_COMMAND_MEMORY set will immediately enable memory
decoding while the BARs are still 0, potentially causing severe PCIe bus
conflicts, IOMMU faults, or kernel panics since the device will intercept
memory accesses to physical address 0.

Should we clear PCI_COMMAND_MEMORY before returning (e.g.,
cmd & ~PCI_COMMAND_MEMORY), relying on the caller's subsequent
pci_restore_state() to safely reprogram the BARs before memory decoding is
formally re-enabled?

> +
> +	return 0;
> +}

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