From: Wei Liu <wei.liu@kernel.org>
To: Linux on Hyper-V List <linux-hyperv@vger.kernel.org>,
linux-pci@vger.kernel.org
Cc: Wei Liu <wei.liu@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 1/2] PCI: Add controller reset method
Date: Mon, 10 Aug 2026 11:55:45 -0700 [thread overview]
Message-ID: <20260810185545.GC2496954@liuwe-devbox-debian-v2.local> (raw)
In-Reply-To: <20260724230844.3259741-2-wei.liu@kernel.org>
Hi Bjorn,
Since this is adding to the PCI reset framework, this patch needs your
approval.
Please see below for my questions. I'm happy to change the code however
you see fit.
On Fri, Jul 24, 2026 at 04:08:42PM -0700, wei.liu@kernel.org wrote:
> From: Wei Liu <wei.liu@kernel.org>
>
> Some PCI controllers provide a function reset mechanism that is not
> advertised in PCI configuration space. Allow them to expose it through an
> optional pci_ops callback.
>
> Add the controller reset method to the standard reset_method interface.
> Prefer FLR and AF FLR by default, and use the controller operation before
> PM and bus reset fallbacks.
>
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> ---
> drivers/pci/pci.c | 22 ++++++++++++++++++++++
> include/linux/pci.h | 3 ++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 77b17b13ee61..4e55da202cad 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4962,6 +4962,27 @@ static int pci_reset_bus_function(struct pci_dev *dev, bool probe)
> return rc;
> }
>
> +static int pci_controller_reset(struct pci_dev *dev, bool probe)
> +{
> + int rc;
> +
> + if (!dev->bus->ops->reset)
> + return -ENOTTY;
> +
> + if (probe)
> + return dev->bus->ops->reset(dev, probe);
> +
> + rc = pci_dev_reset_iommu_prepare(dev);
> + if (rc) {
> + pci_err(dev, "failed to stop IOMMU for a PCI reset: %d\n", rc);
> + return rc;
> + }
> +
> + rc = dev->bus->ops->reset(dev, probe);
> + pci_dev_reset_iommu_done(dev);
> + return rc;
> +}
> +
The first question is whether modelling this on the controller level
is the correct approach.
Please refer to the second patch for the intended usage in the Hyper-V
vPCI code.
Whatever is added here, a new reset_method value will be added to the
table. I chose "controller" to reflect the decision above.
> static int cxl_reset_bus_function(struct pci_dev *dev, bool probe)
> {
> struct pci_dev *bridge;
> @@ -5094,6 +5115,7 @@ const struct pci_reset_fn_method pci_reset_fn_methods[] = {
> { pci_dev_acpi_reset, .name = "acpi" },
> { pcie_reset_flr, .name = "flr" },
> { pci_af_flr, .name = "af_flr" },
> + { pci_controller_reset, .name = "controller" },
The second question is whether this ordering is okay.
Thanks,
Wei
> { pci_pm_reset, .name = "pm" },
> { pci_reset_bus_function, .name = "bus" },
> { cxl_reset_bus_function, .name = "cxl_bus" },
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 64b308b6e61c..d7759ee70670 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -52,7 +52,7 @@
> PCI_STATUS_PARITY)
>
> /* Number of reset methods used in pci_reset_fn_methods array in pci.c */
> -#define PCI_NUM_RESET_METHODS 8
> +#define PCI_NUM_RESET_METHODS 9
>
> #define PCI_RESET_PROBE true
> #define PCI_RESET_DO_RESET false
> @@ -875,6 +875,7 @@ struct pci_ops {
> void __iomem *(*map_bus)(struct pci_bus *bus, unsigned int devfn, int where);
> int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val);
> int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
> + int (*reset)(struct pci_dev *dev, bool probe);
> };
>
> /*
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-08-10 18:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 23:08 [PATCH RFC 0/2] Support Hyper-V vPCI controller reset method wei.liu
2026-07-24 23:08 ` [PATCH RFC 1/2] PCI: Add " wei.liu
2026-07-24 23:16 ` sashiko-bot
2026-08-10 18:55 ` Wei Liu [this message]
2026-07-24 23:08 ` [PATCH RFC 2/2] PCI: hv: Add vPCI device reset support wei.liu
2026-07-24 23:25 ` sashiko-bot
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=20260810185545.GC2496954@liuwe-devbox-debian-v2.local \
--to=wei.liu@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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.