On Fri, Oct 25, 2024 at 02:04:58PM -0600, Alex Williamson wrote: > > I can understand your hesitation, but TBH I've wished for such a thing > in the past. We can already twiddle the secondary bus reset bit using > setpci, but then we don't restore config space of the subordinate > devices and at best we need to remove and rescan those devices. I wasn't going to say it, but I have encountered the setpci method used in the wild, and the results are not always consistent. :) Having the kernel involved is safer, though you should still use it carefully. > As Keith notes in his reply, we can also effectively trigger this same > thing through vfio-pci, so I think we're only making it a little easier > to accomplish through this sysfs attribute. Yes, bad things can happen > if we were to reset a bus of running devices, but I don't know that > it's any more bad than resetting each of those devices individually. If your drivers implement the .reset_prepare and .reset_done callbacks, it's actually okay (in theory) to do this on a bus of running devices. Might even be worth it to emit a warning if you reset running devices that don't implement the callbacks. ? > I would agree that "reset" is not a great name since we're resetting > the subordinate devices and not the bridge device under which this > attribute would appear. Seems there should also be an update to > Documentation/ABI/testing/sysfs-bus-pci in this patch too. Thanks, I'll spin out a v2 soon to change these: Move the attribute to pci_dev bridges only (it's actually easier to find that in sysfs compared to pci_bus attributes, IMO) Rename the attribute to "reset_subordinate" Add the attribute to pci sysfs Documentation.
