All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Ido Schimmel <idosch@nvidia.com>, Petr Machata <petrm@nvidia.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, Amit Cohen <amcohen@nvidia.com>,
	mlxsw@nvidia.com, linux-pci@vger.kernel.org,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH net-next 6/6] mlxsw: pci: Add support for new reset flow
Date: Thu, 13 Apr 2023 12:26:36 +0200	[thread overview]
Message-ID: <20230413102636.GA18500@wunner.de> (raw)
In-Reply-To: <20230329160144.GA2967030@bhelgaas>

On Wed, Mar 29, 2023 at 11:01:44AM -0500, Bjorn Helgaas wrote:
> On Sun, Mar 26, 2023 at 04:53:58PM +0300, Ido Schimmel wrote:
> > On Thu, Mar 23, 2023 at 11:51:15AM -0500, Bjorn Helgaas wrote:
> > > So the first question is why you don't simply use
> > > pci_reset_function(), since it is supposed to cause a reset and do all
> > > the necessary waiting for the device to be ready.

I agree, this driver should use one of the reset helpers provided
by the PCI core.

Not least because if the Downstream Port is hotplug-capable,
fiddling with the Link Disable bit behind the hotplug driver's back
will cause unbinding and rebinding of the device.

> > __pci_reset_function_locked() is another option, but it assumes the
> > device lock was already taken, which is correct during probe, but not
> > when reset is performed as part of devlink reload.

Just call pci_dev_lock() in the devlink reload code path.

> Hmmm, pci_pm_reset() puts the device in D3hot, then back to D0.  Spec
> says that results in "undefined internal Function state," which
> doesn't even sound like a guaranteed reset, but it's what we have, and
> in any case, it does not disable the link.

Per PCIe r6.0.1 sec 5.8, the device undergoes a Soft Reset when moving
from D3hot to D0 (unless the No_Soft_Reset bit is set in the Power
Management Control/Status Register, sec 7.5.2.2).

The driver can set the PCI_DEV_FLAGS_NO_PM_RESET flag if this reset method
doesn't have any effect (via quirk_no_pm_reset()).

We could also discuss moving pci_pm_reset after pci_reset_bus_function
in pci_reset_fn_methods[] if this reset method has little value on the
majority of devices.

Alternatively, if Secondary Bus Reset has the intended effect, the driver
could invoke that directly via pci_reset_bus().

> Spec (PCIe r6.0, sec 6.6.1) says "Disabling a Link causes Downstream
> components to undergo a hot reset."  That seems like it *could* be a
> general-purpose method of doing a reset, and I don't know why the PCI
> core doesn't support it.  Added Alex and Lukas in case they know.

Sounds reasonable to me.

Thanks,

Lukas

      parent reply	other threads:[~2023-04-13 10:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22 16:49 [PATCH net-next 0/6] mlxsw: Add support for new reset flow Petr Machata
2023-03-22 16:49 ` [PATCH net-next 1/6] mlxsw: reg: Move 'mpsc' definition in 'mlxsw_reg_infos' Petr Machata
2023-03-26 13:59   ` Simon Horman
2023-03-22 16:49 ` [PATCH net-next 2/6] mlxsw: reg: Add Management Capabilities Mask Register Petr Machata
2023-03-26 14:00   ` Simon Horman
2023-03-26 14:02   ` Simon Horman
2023-03-27  9:35     ` Petr Machata
2023-03-27  9:53       ` Simon Horman
2023-03-22 16:49 ` [PATCH net-next 3/6] mlxsw: Extend MRSR pack() function to support new commands Petr Machata
2023-03-26 14:02   ` Simon Horman
2023-03-22 16:49 ` [PATCH net-next 4/6] mlxsw: pci: Rename mlxsw_pci_sw_reset() Petr Machata
2023-03-26 14:02   ` Simon Horman
2023-03-22 16:49 ` [PATCH net-next 5/6] mlxsw: pci: Move software reset code to a separate function Petr Machata
2023-03-26 14:03   ` Simon Horman
2023-03-22 16:49 ` [PATCH net-next 6/6] mlxsw: pci: Add support for new reset flow Petr Machata
2023-03-23  9:13   ` Petr Machata
2023-03-23 16:51   ` Bjorn Helgaas
2023-03-26 13:53     ` Ido Schimmel
2023-03-29 16:01       ` Bjorn Helgaas
2023-03-29 17:10         ` Alex Williamson
2023-03-30  8:26           ` Ido Schimmel
2023-03-30 18:49             ` Alex Williamson
2023-04-13  8:10               ` Ido Schimmel
2023-04-13 15:26                 ` Jakub Kicinski
2023-04-13 10:26         ` Lukas Wunner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230413102636.GA18500@wunner.de \
    --to=lukas@wunner.de \
    --cc=alex.williamson@redhat.com \
    --cc=amcohen@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=helgaas@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.