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

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

> [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?

The MHI SoC reset is a device-internal firmware/SoC reset, not a PCI-level
reset. It does not zero the PCI configuration space or BARs, the PCIe link
stays alive during this reset and BARs are maintained by the host PCI
subsystem.

Additionally, the PCI reset framework calls pci_dev_save_and_disable()
before and pci_dev_restore() after the reset method, so config space is
properly managed by the caller.

The reset sequence replicates the existing MHI driver code (mhi_soc_reset(),
mhi_pci_reset_prepare()) which works in production.