From: Bjorn Helgaas <helgaas@kernel.org>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: bhelgaas@google.com, sathyanarayanan.kuppuswamy@linux.intel.com,
rafael.j.wysocki@intel.com, kai.heng.feng@canonical.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
treding@nvidia.com, jonathanh@nvidia.com, kthota@nvidia.com,
mmaddireddy@nvidia.com, sagar.tv@gmail.com
Subject: Re: [PATCH V1] PCI/ASPM: Update saved buffers with latest ASPM configuration
Date: Sat, 28 Jan 2023 12:26:24 -0600 [thread overview]
Message-ID: <20230128182624.GA1412510@bhelgaas> (raw)
In-Reply-To: <20230125133830.20620-1-vidyas@nvidia.com>
On Wed, Jan 25, 2023 at 07:08:30PM +0530, Vidya Sagar wrote:
> Many PCIe device drivers save the configuration state of their respective
> devices during probe and restore the same when their 'slot_reset' hook
> is called through PCIe Error Recovery System.
This strategy of simply restoring config space after a reset is
common, but I think it's only a 90% solution.
After reset, the device is basically in a "fresh poweron" state [1].
At boot-time or for a hot-added device, we do a lot of setup when we
enumerate the device, and assuming that:
- device reset, plus
- current state in the struct pci_dev, plus
- restoring config space
gets all the device and kernel state to the same place is a pretty big
assumption.
That said, we're pretty invested in this strategy for now, and I think
what you propose here is definitely an improvement. Minor comments on
the implementation below.
Bjorn
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/PCI/pci-error-recovery.rst?id=v6.1#n277
> If the system has a change in ASPM policy after the driver's probe is
> called and before error event occurred, 'slot_reset' hook restores the
> PCIe configuration state to what it was at the time of probe but not with
> what it was just before the occurrence of the error event.
> This effectively leads to a mismatch in the ASPM configuration between
> the device and its upstream parent device.
> This patch addresses that issue by updating the saved configuration state
> of the device with the latest info whenever there is a change w.r.t ASPM
> policy.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> drivers/pci/pci.h | 4 ++++
> drivers/pci/pcie/aspm.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 44 insertions(+)
> +++ b/drivers/pci/pci.h
> +void pci_save_aspm_state(struct pci_dev *dev);
> +void pci_restore_aspm_state(struct pci_dev *dev);
This patch only adds calls to these functions in aspm.c, so it doesn't
look like we need declarations here or stubs below.
> +static inline void pci_save_aspm_state(struct pci_dev *dev) { }
> +static inline void pci_restore_aspm_state(struct pci_dev *dev) { }
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 53a1fa306e1e..f25e0440d36b 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -151,6 +151,7 @@ static void pcie_set_clkpm_nocheck(struct pcie_link_state *link, int enable)
> PCI_EXP_LNKCTL_CLKREQ_EN,
> val);
> link->clkpm_enabled = !!enable;
> + pci_save_aspm_state(child);
> }
>
> static void pcie_set_clkpm(struct pcie_link_state *link, int enable)
> @@ -757,6 +758,39 @@ static void pcie_config_aspm_l1ss(struct pcie_link_state *link, u32 state)
> PCI_L1SS_CTL1_L1SS_MASK, val);
> }
>
> +void pci_save_aspm_state(struct pci_dev *dev)
I might be missing something because these look like they should be
static. But the declarations and these being non-static suggest that
you might have something more in mind that isn't part of this patch?
Move these save-state functions higher up if necessary to resolve the
forward reference from pcie_set_clkpm_nocheck().
> +{
> + int i = 0;
> + struct pci_cap_saved_state *save_state;
> + u16 *cap;
> +
> + if (!pci_is_pcie(dev))
> + return;
> +
> + save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> + if (!save_state)
> + return;
> +
> + cap = (u16 *)&save_state->cap.data[0];
> + i++;
"i" looks unnecessary, but I guess I see what you're doing --
mirroring the structure of pci_save_pcie_state() to make sure we put
LNKCTL in the correct element of cap[].
> + pcie_capability_read_word(dev, PCI_EXP_LNKCTL, &cap[i++]);
> +}
> +
> +void pci_restore_aspm_state(struct pci_dev *dev)
No callers for this? And I don't see why you would *need* callers;
this should be restored by pci_restore_pcie_state() already. So this
looks like it could be removed completely.
> +{
> + int i = 0;
> + struct pci_cap_saved_state *save_state;
> + u16 *cap;
> +
> + save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> + if (!save_state)
> + return;
> +
> + cap = (u16 *)&save_state->cap.data[0];
> + i++;
> + pcie_capability_write_word(dev, PCI_EXP_LNKCTL, cap[i++]);
> +}
> +
> void pci_save_aspm_l1ss_state(struct pci_dev *dev)
> {
> struct pci_cap_saved_state *save_state;
> @@ -849,6 +883,12 @@ static void pcie_config_aspm_link(struct pcie_link_state *link, u32 state)
> pcie_config_aspm_dev(parent, upstream);
>
> link->aspm_enabled = state;
> +
> + /* Update latest ASPM configuration in saved context */
> + pci_save_aspm_state(link->downstream);
> + pci_save_aspm_l1ss_state(link->downstream);
> + pci_save_aspm_state(parent);
> + pci_save_aspm_l1ss_state(parent);
> }
>
> static void pcie_config_aspm_path(struct pcie_link_state *link)
> --
> 2.17.1
>
next prev parent reply other threads:[~2023-01-28 18:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 13:38 [PATCH V1] PCI/ASPM: Update saved buffers with latest ASPM configuration Vidya Sagar
2023-01-25 15:01 ` Wysocki, Rafael J
2023-01-25 17:22 ` Vidya Sagar
2023-01-26 11:43 ` Wysocki, Rafael J
2023-01-26 21:22 ` Sathyanarayanan Kuppuswamy
2023-01-27 20:10 ` Bjorn Helgaas
2023-01-28 18:26 ` Bjorn Helgaas [this message]
2024-01-03 10:35 ` [PATCH V2] PCI/ASPM: Update saved buffers with latest ASPM Vidya Sagar
2024-01-03 15:37 ` Kuppuswamy Sathyanarayanan
2024-01-08 12:42 ` [PATCH V3] " Vidya Sagar
2024-02-20 4:07 ` Vidya Sagar
2024-02-20 17:23 ` Bjorn Helgaas
2024-02-22 17:44 ` [PATCH V4] " Vidya Sagar
2024-02-22 18:20 ` Kuppuswamy Sathyanarayanan
2024-02-22 18:54 ` Bjorn Helgaas
2024-02-22 19:54 ` Kuppuswamy Sathyanarayanan
2024-02-22 22:14 ` David E. Box
2024-02-22 20:59 ` Vidya Sagar
2024-03-05 22:03 ` Bjorn Helgaas
2024-03-05 22:35 ` Kuppuswamy Sathyanarayanan
2024-03-06 1:37 ` David E. Box
2024-03-07 22:01 ` Bjorn Helgaas
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=20230128182624.GA1412510@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=jonathanh@nvidia.com \
--cc=kai.heng.feng@canonical.com \
--cc=kthota@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=rafael.j.wysocki@intel.com \
--cc=sagar.tv@gmail.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=treding@nvidia.com \
--cc=vidyas@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.