From: Bjorn Helgaas <helgaas@kernel.org>
To: root <root@hu-msarkar-hyd.qualcomm.com>
Cc: andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org,
jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
konrad.dybcio@linaro.org, manivannan.sadhasivam@linaro.org,
conor+dt@kernel.org, quic_nitegupt@quicinc.com,
quic_shazhuss@quicinc.com, quic_ramkri@quicinc.com,
quic_nayiluri@quicinc.com, quic_krichai@quicinc.com,
quic_vbadigan@quicinc.com, "Nitesh Gupta" <nitegupt@quicinc.com>,
"Mrinmay Sarkar" <quic_msarkar@quicinc.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 3/3] PCI: qcom: Add support for detecting controller level PCIe errors
Date: Wed, 21 Feb 2024 12:50:17 -0600 [thread overview]
Message-ID: <20240221185017.GA1536431@bhelgaas> (raw)
In-Reply-To: <20240221140405.28532-4-root@hu-msarkar-hyd.qualcomm.com>
On Wed, Feb 21, 2024 at 07:34:04PM +0530, root wrote:
> From: Nitesh Gupta <nitegupt@quicinc.com>
>
> Synopsys Controllers provide capabilities to detect various controller
"Synopsys controllers"? "Synopsys" refers to the DesignWare core, but
most of this code is in the qcom driver. If it's qcom-specific, this
should say "Qualcomm controllers".
> level errors. These can range from controller interface error to random
> PCIe configuration errors. This patch intends to add support to detect
> these errors and report it to userspace entity via sysfs, which can take
> appropriate actions to mitigate the errors.
s/This patch intends to add/Add/, so the commit log says what the
patch *does*, not "what it intends to do".
> +
> +/*
> + * Error Reporting DBI register
> + */
Typical style in this file (granted, it's not 100% consistent) is to
make these single-line comments, i.e.,
/* Error Reporting DBI register */
> +#define DBI_DEVICE_CONTROL_DEVICE_STATUS 0x78
> +#define DBI_ROOT_CONTROL_ROOT_CAPABILITIES_REG 0x8c
Most other #defines in this file use upper-case hex.
> +#define PCIE_AER_EXT_CAP_ID 0x01
Why not the existing PCI_EXT_CAP_ID_ERR? If this is the standard PCIe
AER stuff, we shouldn't make it needlessly device-specific.
> +#define PCI_EXT_CAP_RASDP_ID 0x0b
Looks like possibly PCI_EXT_CAP_ID_VNDR? Capability IDs are
definitely not device-specific. The fact that a PCI_EXT_CAP_ID_VNDR
capability in a device with Vendor ID PCI_VENDOR_ID_QCOM has a
qcom-specific meaning is obviously specific to qcom, but the
Capability ID itself is not.
> +/* DBI_ROOT_CONTROL_ROOT_CAPABILITIES_REG register fields */
> +#define PCIE_CAP_SYS_ERR_ON_CORR_ERR_EN BIT(0)
> +#define PCIE_CAP_SYS_ERR_ON_NON_FATAL_ERR_EN BIT(1)
> +#define PCIE_CAP_SYS_ERR_ON_FATAL_ERR_EN BIT(2)
> +
> +/* DBI_DEVICE_CONTROL_DEVICE_STATUS register fields */
> +#define PCIE_CAP_UNSUPPORT_REQ_REP_EN BIT(3)
> +#define PCIE_CAP_FATAL_ERR_REPORT_EN BIT(2)
> +#define PCIE_CAP_NON_FATAL_ERR_REPORT_EN BIT(1)
> +#define PCIE_CAP_CORR_ERR_REPORT_EN BIT(0)
These look like alternate ways to access the generic PCIe Capability.
If that's the case, either use the existing PCI_EXP_RTCTL_SECEE,
PCI_EXP_DEVCTL_CERE, etc., or at least match the "RTCTL_SECEE" parts
of the names so we can see the connection.
> +/* DBI_ADV_ERR_CAP_CTRL_OFF register fields */
> +#define ECRC_GEN_EN BIT(6)
> +#define ECRC_CHECK_EN BIT(8)
Do these correspond to PCI_ERR_CAP_ECRC_GENE, PCI_ERR_CAP_ECRC_CHKE?
> +/* DBI_ROOT_ERR_CMD_OFF register fields */
> +#define CORR_ERR_REPORTING_EN BIT(0)
> +#define NON_FATAL_ERR_REPORTING_EN BIT(1)
> +#define FATAL_ERR_REPORTING_EN BIT(2)
PCI_ERR_ROOT_CMD_COR_EN, etc?
> +static void qcom_pcie_enable_error_reporting_2_7_0(struct qcom_pcie *pcie)
> +{
> + ...
> + val = readl(pci->dbi_base + DBI_DEVICE_CONTROL_DEVICE_STATUS);
> + val |= (PCIE_CAP_CORR_ERR_REPORT_EN | PCIE_CAP_NON_FATAL_ERR_REPORT_EN |
> + PCIE_CAP_FATAL_ERR_REPORT_EN | PCIE_CAP_UNSUPPORT_REQ_REP_EN);
> + writel(val, pci->dbi_base + DBI_DEVICE_CONTROL_DEVICE_STATUS);
Is there any way to split the AER part (specified by the PCIe spec)
from the qcom-specific (or dwc-specific) part? This looks an awful
lot like pci_enable_pcie_error_reporting(), and we should do this in
the PCI core in a generic way if possible.
> + val = readl(pci->dbi_base + DBI_ROOT_CONTROL_ROOT_CAPABILITIES_REG);
> + val |= (PCIE_CAP_SYS_ERR_ON_CORR_ERR_EN | PCIE_CAP_SYS_ERR_ON_NON_FATAL_ERR_EN |
> + PCIE_CAP_SYS_ERR_ON_FATAL_ERR_EN);
> + writel(val, pci->dbi_base + DBI_ROOT_CONTROL_ROOT_CAPABILITIES_REG);
Bjorn
next prev parent reply other threads:[~2024-02-21 18:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 14:04 [PATCH v1 0/3] Add support for detecting Controller Level PCIe Errors root
2024-02-21 14:04 ` [PATCH v1 1/3] dt-bindings: PCI: qcom: Add global irq support for SA8775p root
2024-02-21 14:28 ` Krzysztof Kozlowski
2024-02-21 14:31 ` Konrad Dybcio
2024-02-21 14:33 ` Krzysztof Kozlowski
2024-02-22 13:46 ` Mrinmay Sarkar
2024-02-22 14:19 ` Krzysztof Kozlowski
2024-02-21 14:04 ` [PATCH v1 2/3] arm64: dts: qcom: sa8775p: Enable " root
2024-02-21 14:04 ` [PATCH v1 3/3] PCI: qcom: Add support for detecting controller level PCIe errors root
2024-02-21 14:35 ` Krzysztof Kozlowski
2024-02-21 18:50 ` Bjorn Helgaas [this message]
2024-02-22 12:38 ` Bjorn Helgaas
2024-02-21 21:00 ` Frank Li
2024-02-22 11:01 ` kernel test robot
2024-02-22 12:39 ` kernel test robot
2024-02-22 5:22 ` [PATCH v1 0/3] Add support for detecting Controller Level PCIe Errors Manivannan Sadhasivam
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=20240221185017.GA1536431@bhelgaas \
--to=helgaas@kernel.org \
--cc=andersson@kernel.org \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=nitegupt@quicinc.com \
--cc=quic_krichai@quicinc.com \
--cc=quic_msarkar@quicinc.com \
--cc=quic_nayiluri@quicinc.com \
--cc=quic_nitegupt@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
--cc=quic_vbadigan@quicinc.com \
--cc=robh@kernel.org \
--cc=root@hu-msarkar-hyd.qualcomm.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.