From: Bjorn Helgaas <helgaas@kernel.org>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: adrian.hunter@intel.com, ulf.hansson@linaro.org,
Victor Shih <victor.shih@genesyslogic.com.tw>,
Ben Chuang <benchuanggli@gmail.com>,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mmc: sdhci-pci-gli: GL975x: Mask rootport's replay timer timeout during suspend
Date: Fri, 5 Jan 2024 15:19:11 -0600 [thread overview]
Message-ID: <20240105211911.GA1867400@bhelgaas> (raw)
In-Reply-To: <20231221032147.434647-1-kai.heng.feng@canonical.com>
On Thu, Dec 21, 2023 at 11:21:47AM +0800, Kai-Heng Feng wrote:
> Spamming `lspci -vv` can still observe the replay timer timeout error
> even after commit 015c9cbcf0ad ("mmc: sdhci-pci-gli: GL9750: Mask the
> replay timer timeout of AER"), albeit with a lower reproduce rate.
I'm not sure what this is telling me. By "spamming `lspci -vv`, do
you mean that if you run lspci continually, you still see Replay Timer
Timeout logged, e.g.,
CESta: ... Timeout+
015c9cbcf0ad uses hard-coded PCI_GLI_9750_CORRERR_MASK offset and
PCI_GLI_9750_CORRERR_MASK_REPLAY_TIMER_TIMEOUT value, which look like
they *could* be PCI_ERR_COR_MASK and PCI_ERR_COR_REP_TIMER, but
without the lspci output I can't tell for sure. If they are, it would
be nice to use the generic macros instead of defining new ones so it's
easier to analyze PCI_ERR_COR_MASK usage.
If 015c9cbcf0ad is updating the generic PCI_ERR_COR_MASK, it should
only prevent sending ERR_COR. It should not affect the *logging* in
PCI_ERR_COR_STATUS (see PCIe r6.0, sec 6.2.3.2.2), so it shouldn't
affect the lspci output.
> Such AER interrupt can still prevent the system from suspending, so let
> root port mask and unmask replay timer timeout during suspend and
> resume, respectively.
015c9cbcf0ad looks like it masks PCI_ERR_COR_REP_TIMER in the gl975x
Endpoint, while this patch masks it in the upstream bridge (which
might be either a Root Port or a Switch Downstream Port, so the
subject and this sentence are not quite right).
015c9cbcf0ad says it is related to a hardware defect, and maybe this
patch is also (mention it if so). Both patches can prevent ERR_COR
messages and the eventual AER interrupt, depending on whether the
Downstream Port or the Endpoint detects the Replay Timer Timeout.
Maybe this should have a Fixes: tag for 015c9cbcf0ad to try to keep
these together?
If 015c9cbcf0ad is actually updating PCI_ERR_COR_MASK, it would be
nice to clean that up, too. And maybe PCI_ERR_COR_REP_TIMER should be
masked/restored at the same place for both the Downstream Port and the
Endpoint?
> +#ifdef CONFIG_PCIEAER
> +static void mask_replay_timer_timeout(struct pci_dev *pdev)
> +{
> + struct pci_dev *parent = pci_upstream_bridge(pdev);
> + u32 val;
> +
> + if (!parent || !parent->aer_cap)
> + return;
> +
> + pci_read_config_dword(parent, parent->aer_cap + PCI_ERR_COR_MASK, &val);
> + val |= PCI_ERR_COR_REP_TIMER;
> + pci_write_config_dword(parent, parent->aer_cap + PCI_ERR_COR_MASK, val);
> +}
> +
> +static void unmask_replay_timer_timeout(struct pci_dev *pdev)
> +{
> + struct pci_dev *parent = pci_upstream_bridge(pdev);
> + u32 val;
> +
> + if (!parent || !parent->aer_cap)
> + return;
> +
> + pci_read_config_dword(pdev, parent->aer_cap + PCI_ERR_COR_MASK, &val);
> + val &= ~PCI_ERR_COR_REP_TIMER;
I think I would save the previous PCI_ERR_COR_REP_TIMER value and
restore it here, so it is preserved if there is ever a generic
interface via sysfs or similar to manage correctable error masking.
> + pci_write_config_dword(pdev, parent->aer_cap + PCI_ERR_COR_MASK, val);
> +}
next prev parent reply other threads:[~2024-01-05 21:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 3:21 [PATCH v2] mmc: sdhci-pci-gli: GL975x: Mask rootport's replay timer timeout during suspend Kai-Heng Feng
2024-01-03 10:52 ` Ulf Hansson
2024-01-04 4:10 ` Kai-Heng Feng
2024-01-04 19:42 ` Adrian Hunter
2024-01-05 21:19 ` Bjorn Helgaas [this message]
2024-01-12 5:14 ` Kai-Heng Feng
2024-01-12 17:37 ` Bjorn Helgaas
2024-01-18 6:40 ` Kai-Heng Feng
2024-01-19 22:40 ` Bjorn Helgaas
2024-03-21 10:05 ` Kai-Heng Feng
2024-03-22 16:43 ` Bjorn Helgaas
2024-03-25 2:02 ` Kai-Heng Feng
2024-03-25 19:02 ` Bjorn Helgaas
2024-03-26 1:52 ` Kai-Heng Feng
2024-03-26 21:19 ` 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=20240105211911.GA1867400@bhelgaas \
--to=helgaas@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=benchuanggli@gmail.com \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=victor.shih@genesyslogic.com.tw \
/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