| Message ID | fe4156c6b9d0f7e8478ae93137586ec88051013d.1700047319.git.petrm@nvidia.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 3ed48c80b28d8dcd584d6ddaf00c75b7673e1a05 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | mlxsw: Add support for new reset flow | expand |
+ linux-pci@vger.kernel.org On Wed, Nov 15, 2023 at 01:17:16PM +0100, Petr Machata wrote: > From: Ido Schimmel <idosch@nvidia.com> > > Spectrum-{1,2,3,4} devices report that a D3hot->D0 transition causes a > reset (i.e., they advertise NoSoftRst-). However, this transition does > not have any effect on the device: It continues to be operational and > network ports remain up. Advertising this support makes it seem as if a > PM reset is viable for these devices. Mark it as unavailable to skip it > when testing reset methods. > > Before: > > # cat /sys/bus/pci/devices/0000\:03\:00.0/reset_method > pm bus > > After: > > # cat /sys/bus/pci/devices/0000\:03\:00.0/reset_method > bus > > Signed-off-by: Ido Schimmel <idosch@nvidia.com> > Acked-by: Bjorn Helgaas <bhelgaas@google.com> > Signed-off-by: Petr Machata <petrm@nvidia.com> Thanks, my understanding is that this matches the use-case for which quirk_no_pm_reset was introduced. > --- > drivers/pci/quirks.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index ea476252280a..d208047d1b8f 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3786,6 +3786,19 @@ static void quirk_no_pm_reset(struct pci_dev *dev) > DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID, > PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset); > > +/* > + * Spectrum-{1,2,3,4} devices report that a D3hot->D0 transition causes a reset > + * (i.e., they advertise NoSoftRst-). However, this transition does not have > + * any effect on the device: It continues to be operational and network ports > + * remain up. Advertising this support makes it seem as if a PM reset is viable > + * for these devices. Mark it as unavailable to skip it when testing reset > + * methods. > + */ > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcb84, quirk_no_pm_reset); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf6c, quirk_no_pm_reset); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf70, quirk_no_pm_reset); > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf80, quirk_no_pm_reset); > + > /* > * Thunderbolt controllers with broken MSI hotplug signaling: > * Entire 1st generation (Light Ridge, Eagle Ridge, Light Peak) and part > -- > 2.41.0 >
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index ea476252280a..d208047d1b8f 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3786,6 +3786,19 @@ static void quirk_no_pm_reset(struct pci_dev *dev) DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset); +/* + * Spectrum-{1,2,3,4} devices report that a D3hot->D0 transition causes a reset + * (i.e., they advertise NoSoftRst-). However, this transition does not have + * any effect on the device: It continues to be operational and network ports + * remain up. Advertising this support makes it seem as if a PM reset is viable + * for these devices. Mark it as unavailable to skip it when testing reset + * methods. + */ +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcb84, quirk_no_pm_reset); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf6c, quirk_no_pm_reset); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf70, quirk_no_pm_reset); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf80, quirk_no_pm_reset); + /* * Thunderbolt controllers with broken MSI hotplug signaling: * Entire 1st generation (Light Ridge, Eagle Ridge, Light Peak) and part