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
prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).