Re: [PATCH] PCI/DPC: Add Software Trigger as reset method

[Lukas Wunner <lukas@wunner.de>]

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