On Fri, May 23, 2025 at 07:33:16AM +0200, Lukas Wunner wrote: > On Thu, May 22, 2025 at 06:19:56PM +0200, Niklas Cassel wrote: > > As you know the reset_slot() callback patches were merged recently. > > > > Wilfred and I (mostly Wilfred), have been debugging DMA issues after the > > reset_slot() callback has been invoked. The issue is reproduced when MPS > > configuration is set to performance, but might be applicable for other > > MPS configurations as well. The problem appears to be that reset_slot() > > feature does not respect/restore the MPS configuration. > > The Device Control register (and thus the MPS setting) is saved via: > > pci_save_state() > pci_save_pcie_state() > > So either you're missing a call to pci_restore_state() after reset, > or you're missing a call to pci_save_state() after changing MPS, > or MPS is somehow overwritten after pci_restore_state(). > Which one is it? > I think the issue is that the PCI bridge is getting reset while trying to reset the PCI device. And in the reset path, we only save the config space of the *device*, not the bridge. As seen from the lspci output shared by Niklas, the content of the PCI bridge seem to be diverged. Since the slot_reset() callback resets the whole Root Complex (if there is a single Root port), then the config space of the Root port/bridge needs to be saved and restored as well. I believe pcibios_reset_secondary_bus() is not supposed to change the config space of the root port. As per the definition of the "Secondary Bus Reset" field in the Bridge Control Register, r3.0, sec 7.5.3.6: "Port configuration registers must not be changed, except as required to update Port status." So pci_reset_secondary_bus() is not changing the config space, but slot_reset() does. Are we plugging slot_reset() at the wrong place? - Mani -- மணிவண்ணன் சதாசிவம்
