From: Raphael Norwitz <raphael.norwitz@nutanix.com>
To: Amey Narkhede <ameynarkhede03@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
Raphael Norwitz <raphael.norwitz@nutanix.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kw@linux.com" <kw@linux.com>,
Shanker Donthineni <sdonthineni@nvidia.com>,
Sinan Kaya <okaya@kernel.org>, Len Brown <lenb@kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH v9 2/8] PCI: Add new array for keeping track of ordering of reset methods
Date: Sun, 11 Jul 2021 16:42:46 +0000 [thread overview]
Message-ID: <20210711164241.GB30406@raphael-debian-dev> (raw)
In-Reply-To: <20210705142138.2651-3-ameynarkhede03@gmail.com>
On Mon, Jul 05, 2021 at 07:51:32PM +0530, Amey Narkhede wrote:
> Introduce a new array reset_methods in struct pci_dev to keep track of
> reset mechanisms supported by the device and their ordering.
>
> Also refactor probing and reset functions to take advantage of calling
> convention of reset functions.
>
> Co-developed-by: Alex Williamson <alex.williamson@redhat.com>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
> ---
> drivers/pci/pci.c | 92 ++++++++++++++++++++++++++-------------------
> drivers/pci/pci.h | 9 ++++-
> drivers/pci/probe.c | 5 +--
> include/linux/pci.h | 7 ++++
> 4 files changed, 70 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index fefa6d7b3..42440cb10 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -72,6 +72,14 @@ static void pci_dev_d3_sleep(struct pci_dev *dev)
> msleep(delay);
> }
>
> +int pci_reset_supported(struct pci_dev *dev)
> +{
> + u8 null_reset_methods[PCI_NUM_RESET_METHODS] = { 0 };
> +
> + return memcmp(null_reset_methods,
> + dev->reset_methods, sizeof(null_reset_methods));
> +}
> +
> #ifdef CONFIG_PCI_DOMAINS
> int pci_domains_supported = 1;
> #endif
> @@ -5104,6 +5112,15 @@ static void pci_dev_restore(struct pci_dev *dev)
> err_handler->reset_done(dev);
> }
>
> +const struct pci_reset_fn_method pci_reset_fn_methods[] = {
> + { },
> + { &pci_dev_specific_reset, .name = "device_specific" },
> + { &pcie_reset_flr, .name = "flr" },
> + { &pci_af_flr, .name = "af_flr" },
> + { &pci_pm_reset, .name = "pm" },
> + { &pci_reset_bus_function, .name = "bus" },
> +};
> +
> /**
> * __pci_reset_function_locked - reset a PCI device function while holding
> * the @dev mutex lock.
> @@ -5126,65 +5143,62 @@ static void pci_dev_restore(struct pci_dev *dev)
> */
> int __pci_reset_function_locked(struct pci_dev *dev)
> {
> - int rc;
> + int i, m, rc = -ENOTTY;
>
> might_sleep();
>
> /*
> - * A reset method returns -ENOTTY if it doesn't support this device
> - * and we should try the next method.
> + * A reset method returns -ENOTTY if it doesn't support this device and
> + * we should try the next method.
> *
> - * If it returns 0 (success), we're finished. If it returns any
> - * other error, we're also finished: this indicates that further
> - * reset mechanisms might be broken on the device.
> + * If it returns 0 (success), we're finished. If it returns any other
> + * error, we're also finished: this indicates that further reset
> + * mechanisms might be broken on the device.
> */
> - rc = pci_dev_specific_reset(dev, 0);
> - if (rc != -ENOTTY)
> - return rc;
> - rc = pcie_reset_flr(dev, 0);
> - if (rc != -ENOTTY)
> - return rc;
> - rc = pci_af_flr(dev, 0);
> - if (rc != -ENOTTY)
> - return rc;
> - rc = pci_pm_reset(dev, 0);
> - if (rc != -ENOTTY)
> - return rc;
> - return pci_reset_bus_function(dev, 0);
> + for (i = 0; i < PCI_NUM_RESET_METHODS && (m = dev->reset_methods[i]); i++) {
> + rc = pci_reset_fn_methods[m].reset_fn(dev, 0);
> + if (!rc)
> + return 0;
> + if (rc != -ENOTTY)
> + return rc;
> + }
> +
> + return -ENOTTY;
> }
> EXPORT_SYMBOL_GPL(__pci_reset_function_locked);
>
> /**
> - * pci_probe_reset_function - check whether the device can be safely reset
> - * @dev: PCI device to reset
> + * pci_init_reset_methods - check whether device can be safely reset
> + * and store supported reset mechanisms.
> + * @dev: PCI device to check for reset mechanisms
> *
> * Some devices allow an individual function to be reset without affecting
> * other functions in the same device. The PCI device must be responsive
> - * to PCI config space in order to use this function.
> + * to reads and writes to its PCI config space in order to use this function.
> *
> - * Returns 0 if the device function can be reset or negative if the
> - * device doesn't support resetting a single function.
> + * Stores reset mechanisms supported by device in reset_methods byte array
> + * which is a member of struct pci_dev.
> */
> -int pci_probe_reset_function(struct pci_dev *dev)
> +void pci_init_reset_methods(struct pci_dev *dev)
> {
> - int rc;
> + int i, n, rc;
> + u8 reset_methods[PCI_NUM_RESET_METHODS] = { 0 };
> +
> + n = 0;
> +
> + BUILD_BUG_ON(ARRAY_SIZE(pci_reset_fn_methods) != PCI_NUM_RESET_METHODS);
>
> might_sleep();
>
> - rc = pci_dev_specific_reset(dev, 1);
> - if (rc != -ENOTTY)
> - return rc;
> - rc = pcie_reset_flr(dev, 1);
> - if (rc != -ENOTTY)
> - return rc;
> - rc = pci_af_flr(dev, 1);
> - if (rc != -ENOTTY)
> - return rc;
> - rc = pci_pm_reset(dev, 1);
> - if (rc != -ENOTTY)
> - return rc;
> + for (i = 1; i < PCI_NUM_RESET_METHODS; i++) {
> + rc = pci_reset_fn_methods[i].reset_fn(dev, 1);
> + if (!rc)
> + reset_methods[n++] = i;
> + else if (rc != -ENOTTY)
> + break;
> + }
>
> - return pci_reset_bus_function(dev, 1);
> + memcpy(dev->reset_methods, reset_methods, sizeof(reset_methods));
> }
>
> /**
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 37c913bbc..db1ad94e7 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -33,7 +33,8 @@ enum pci_mmap_api {
> int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vmai,
> enum pci_mmap_api mmap_api);
>
> -int pci_probe_reset_function(struct pci_dev *dev);
> +int pci_reset_supported(struct pci_dev *dev);
> +void pci_init_reset_methods(struct pci_dev *dev);
> int pci_bridge_secondary_bus_reset(struct pci_dev *dev);
> int pci_bus_error_reset(struct pci_dev *dev);
>
> @@ -606,6 +607,12 @@ struct pci_dev_reset_methods {
> int (*reset)(struct pci_dev *dev, int probe);
> };
>
> +struct pci_reset_fn_method {
> + int (*reset_fn)(struct pci_dev *pdev, int probe);
> + char *name;
> +};
> +
> +extern const struct pci_reset_fn_method pci_reset_fn_methods[];
> #ifdef CONFIG_PCI_QUIRKS
> int pci_dev_specific_reset(struct pci_dev *dev, int probe);
> #else
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index a95252113..a3e9a9c88 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2406,9 +2406,8 @@ static void pci_init_capabilities(struct pci_dev *dev)
> pci_rcec_init(dev); /* Root Complex Event Collector */
>
> pcie_report_downtraining(dev);
> -
> - if (pci_probe_reset_function(dev) == 0)
> - dev->reset_fn = 1;
> + pci_init_reset_methods(dev);
> + dev->reset_fn = pci_reset_supported(dev);
> }
>
> /*
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d432428fd..9f3e85f33 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -49,6 +49,9 @@
> PCI_STATUS_SIG_TARGET_ABORT | \
> PCI_STATUS_PARITY)
>
> +/* Number of reset methods used in pci_reset_fn_methods array in pci.c */
> +#define PCI_NUM_RESET_METHODS 6
> +
> /*
> * The PCI interface treats multi-function devices as independent
> * devices. The slot/function address of each device is encoded
> @@ -506,6 +509,10 @@ struct pci_dev {
> char *driver_override; /* Driver name to force a match */
>
> unsigned long priv_flags; /* Private flags for the PCI driver */
> + /*
> + * See pci_reset_fn_methods array in pci.c for ordering.
> + */
> + u8 reset_methods[PCI_NUM_RESET_METHODS]; /* Reset methods ordered by priority */
> };
>
> static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
> --
> 2.32.0
>
>
next prev parent reply other threads:[~2021-07-11 16:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 14:21 [PATCH v9 0/8] Expose and manage PCI device reset Amey Narkhede
2021-07-05 14:21 ` [PATCH v9 1/8] PCI: Add pcie_reset_flr to follow calling convention of other reset methods Amey Narkhede
2021-07-05 14:37 ` Amey Narkhede
2021-07-08 20:24 ` Alex Williamson
2021-07-11 16:40 ` Raphael Norwitz
2021-07-05 14:21 ` [PATCH v9 2/8] PCI: Add new array for keeping track of ordering of " Amey Narkhede
2021-07-11 16:42 ` Raphael Norwitz [this message]
2021-07-14 13:13 ` Shanker R Donthineni
2021-07-05 14:21 ` [PATCH v9 3/8] PCI: Remove reset_fn field from pci_dev Amey Narkhede
2021-07-05 14:21 ` [PATCH v9 4/8] PCI/sysfs: Allow userspace to query and set device reset mechanism Amey Narkhede
2021-07-06 5:16 ` Leon Romanovsky
2021-07-11 16:51 ` Raphael Norwitz
2021-07-14 11:59 ` Amey Narkhede
2021-07-05 14:21 ` [PATCH v9 5/8] PCI: Define a function to set ACPI_COMPANION in pci_dev Amey Narkhede
2021-07-05 14:21 ` [PATCH v9 6/8] PCI: Setup ACPI fwnode early and at the same time with OF Amey Narkhede
2021-07-05 14:21 ` [PATCH v9 7/8] PCI: Add support for ACPI _RST reset method Amey Narkhede
2021-07-05 14:21 ` [PATCH v9 8/8] PCI: Change the type of probe argument in reset functions Amey Narkhede
2021-07-05 23:39 ` kernel test robot
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=20210711164241.GB30406@raphael-debian-dev \
--to=raphael.norwitz@nutanix.com \
--cc=alex.williamson@redhat.com \
--cc=ameynarkhede03@gmail.com \
--cc=bhelgaas@google.com \
--cc=kw@linux.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sdonthineni@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