On Tue, Nov 29, 2022 at 08:27:43AM -0800, Sathyanarayanan Kuppuswamy wrote: > On 11/28/22 11:35 PM, Lukas Wunner wrote: > > Add DPC Software Trigger as a reset method to be used for silicon > > validation among other things: > > > > # echo dpc_sw_trigger > reset_method > > # echo 1 > reset > > > > After validating DPC, the default reset_method(s) may be reinstated: > > > > # echo default > reset_method > > > > Writing the DPC Control Register requires that control was granted by > > firmware, so expose the reset_method only if DPC is native. (And AER, > > which must always be granted or denied in unison per PCI Firmware Spec > > r3.3 table 4-5.) > > > > The reset attribute in sysfs is meant to reset a single PCI Function, > > but DPC resets the entire hierarchy below the parent. So only expose > > the reset method on PCI Functions without siblings or children. > > Checking for that may happen both *before* the PCI Function has been > > added to the bus list (via pci_device_add() -> pci_init_capabilities()) > > and *after* (via reset_method_store()), hence differentiate between > > those two cases on reset probing. > > Does this mean you want to only allow this reset method for DPC capable > ports without any devices attached to it? If yes, why not use other > reset methods available? This reset method is allowed if the DPC-capable port has a single child device and that child has no siblings or descendants. And the reset is performed by echoing 1 to the single child's reset attribute in sysfs. Those are the same semantics as the Secondary Bus Reset method. Thanks, Lukas
