On Wed, Sep 19, 2018 at 04:30:32PM +0000, Sinan Kaya wrote:
> We need a contract between the reset API users and the PCI core about the
> types of reset that a user needs vs. what PCI core can do internally.
> If a platform supports hotplug, we need to do hotplug reset as an example.
>
> Expose the reset types to the drivers and try different reset types based
> on the new reset_type parameter.
>
> Most users are expected to use PCI_RESET_ANY, PCI_RESET_FUNC or
> PCI_RESET_LINK parameters.
I understand the words above, but I don't really understand the
motivation behind this. Can you help flesh that out a bit?
I guess there's a problem being solved by these patches, and it would
help a lot to have some details about what it is.
It would be ideal if we could offer some guidance, probably as code
comments, to help driver writers choose the correct reset type.
> + if (reset_type & PCI_RESET_FLR) {
> + if (pcie_has_flr(dev)) {
> + rc = pcie_flr(dev);
> + if (rc != -ENOTTY)
> + return rc;
> + }
> + rc = pci_af_flr(dev, 0);
This is a tangent and not material for the current series, so just
file it away so as not to delay this series, but is there any way we
can get rid of the "probe" arguments? Maybe do all the probes at
enumeration-time and remember the results?
I know there are one or two cases where you need to look at more than
one device, e.g., a secondary bus reset might be possible if there's
only one device and not otherwise, but it seems like in most cases
this is a property of the individual device.
Bjorn
