From: poza@codeaurora.org
To: Ray Jui <ray.jui@broadcom.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Bjorn Helgaas <helgaas@kernel.org>,
linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com, linux-pci@vger.kernel.org,
linux-pci-owner@vger.kernel.org
Subject: Re: [PATCH v2 4/5] PCI: iproc: Reject unconfigured physical functions from PAXC
Date: Tue, 12 Jun 2018 14:00:11 +0530 [thread overview]
Message-ID: <2f545a86aa5433526b17071d64f68e50@codeaurora.org> (raw)
In-Reply-To: <1528762867-16823-5-git-send-email-ray.jui@broadcom.com>
On 2018-06-12 05:51, Ray Jui wrote:
> PAXC is an emulated PCIe root complex internally in various Broadcom
> based SoCs. PAXC internally connects to the embedded network processor
> within these SoCs, with the embedeed network processor exposed as an
> endpoint device
>
> The number of physical functions from the embedded network processor
> that can be accessed depend on the firmware configuration.
> Unfortunately, due to an ASIC bug, unconfigured physical functions
> cannot
> be properly hidden from the root complex during enumerattion. As a
> result, config write access to these unconfigured physical functions
> during enumeration will cause a bus lock up on the embedded network
> processor
>
> Fortunately, these unconfigured physical functions contain a very
> specific, staled PCIe device ID 0x168e. By making use of this device
> ID,
> one is able to terminate the enumeration early in the vendor/device ID
> config read
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> ---
> drivers/pci/host/pcie-iproc.c | 26 +++++++++++++++++++++++++-
> drivers/pci/host/pcie-iproc.h | 5 +++++
> 2 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pcie-iproc.c
> b/drivers/pci/host/pcie-iproc.c
> index 0804aa2..59be1e0 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -582,6 +582,25 @@ static int iproc_pcie_config_read(struct pci_bus
> *bus, unsigned int devfn,
> if (size <= 2)
> *val = (data >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
>
> + /*
> + * For PAXC and PAXCv2, the total number of PFs that one can
> enumerate
> + * depends on the firmware configuration. Unfortunately, due to an
> ASIC
> + * bug, unconfigured PFs cannot be properly hidden from the root
> + * complex. As a result, write access to these PFs will cause bus
> lock
> + * up on the embedded processor
> + *
> + * Since all unconfigured PFs are left with an incorrect, staled
> device
> + * ID of 0x168e (PCI_DEVICE_ID_NX2_57810), we try to catch those
> access
> + * early here and reject them all
> + */
> +#define DEVICE_ID_MASK 0xffff0000
> +#define DEVICE_ID_SHIFT 16
> + if (pcie->rej_unconfig_pf &&
> + (where & CFG_ADDR_REG_NUM_MASK) == PCI_VENDOR_ID)
> + if ((*val & DEVICE_ID_MASK) ==
> + (PCI_DEVICE_ID_NX2_57810 << DEVICE_ID_SHIFT))
> + return PCIBIOS_FUNC_NOT_SUPPORTED;
> +
> return PCIBIOS_SUCCESSFUL;
> }
>
> @@ -681,7 +700,7 @@ static int iproc_pcie_config_read32(struct pci_bus
> *bus, unsigned int devfn,
> struct iproc_pcie *pcie = iproc_data(bus);
>
> iproc_pcie_apb_err_disable(bus, true);
> - if (pcie->type == IPROC_PCIE_PAXB_V2)
> + if (pcie->iproc_cfg_read)
> ret = iproc_pcie_config_read(bus, devfn, where, size, val);
> else
> ret = pci_generic_config_read32(bus, devfn, where, size, val);
> @@ -1336,6 +1355,7 @@ static int iproc_pcie_rev_init(struct iproc_pcie
> *pcie)
> break;
> case IPROC_PCIE_PAXB:
> regs = iproc_pcie_reg_paxb;
> + pcie->iproc_cfg_read = true;
> pcie->has_apb_err_disable = true;
> if (pcie->need_ob_cfg) {
> pcie->ob_map = paxb_ob_map;
> @@ -1358,10 +1378,14 @@ static int iproc_pcie_rev_init(struct
> iproc_pcie *pcie)
> case IPROC_PCIE_PAXC:
> regs = iproc_pcie_reg_paxc;
> pcie->ep_is_internal = true;
> + pcie->iproc_cfg_read = true;
> + pcie->rej_unconfig_pf = true;
> break;
> case IPROC_PCIE_PAXC_V2:
> regs = iproc_pcie_reg_paxc_v2;
> pcie->ep_is_internal = true;
> + pcie->iproc_cfg_read = true;
> + pcie->rej_unconfig_pf = true;
> pcie->need_msi_steer = true;
> break;
> default:
> diff --git a/drivers/pci/host/pcie-iproc.h
> b/drivers/pci/host/pcie-iproc.h
> index 9d5cfee..4f03ea5 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -58,6 +58,9 @@ struct iproc_msi;
> * @phy: optional PHY device that controls the Serdes
> * @map_irq: function callback to map interrupts
> * @ep_is_internal: indicates an internal emulated endpoint device is
> connected
> + * @iproc_cfg_read: indicates the iProc config read function should be
> used
> + * @rej_unconfig_pf: indicates the root complex needs to detect and
> reject
> + * enumeration against unconfigured physical functions emulated in the
> ASIC
> * @has_apb_err_disable: indicates the controller can be configured to
> prevent
> * unsupported request from being forwarded as an APB bus error
> * @fix_paxc_cap: indicates the controller has corrupted capability
> list in its
> @@ -86,6 +89,8 @@ struct iproc_pcie {
> struct phy *phy;
> int (*map_irq)(const struct pci_dev *, u8, u8);
> bool ep_is_internal;
> + bool iproc_cfg_read;
> + bool rej_unconfig_pf;
> bool has_apb_err_disable;
> bool fix_paxc_cap;
Reviewed-by: Oza Pawandeep <poza@codeaurora.org>
next prev parent reply other threads:[~2018-06-12 8:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 0:21 [PATCH v2 0/5] Improve Broadcom PAXC support Ray Jui
2018-06-12 0:21 ` [PATCH v2 1/5] PCI: iproc: Activate PAXC bridge quirk for more devices Ray Jui
2018-06-12 8:30 ` poza
2018-07-09 17:32 ` Ray Jui
2018-07-11 13:11 ` Bjorn Helgaas
2018-07-11 16:52 ` Ray Jui
2018-06-12 0:21 ` [PATCH v2 2/5] PCI: iproc: Fix up corrupted PAXC root complex config registers Ray Jui
2018-06-12 8:27 ` poza
2018-06-12 12:23 ` poza
2018-06-12 16:56 ` Ray Jui
2018-06-12 0:21 ` [PATCH v2 3/5] PCI: iproc: Disable MSI parsing in certain PAXC blocks Ray Jui
2018-06-12 8:29 ` poza
2018-06-12 16:58 ` Ray Jui
2018-06-12 17:44 ` poza
2018-06-12 0:21 ` [PATCH v2 4/5] PCI: iproc: Reject unconfigured physical functions from PAXC Ray Jui
2018-06-12 8:30 ` poza [this message]
2018-06-12 0:21 ` [PATCH v2 5/5] PCI: iproc: Reduce inbound/outbound mapping print level Ray Jui
2018-06-12 8:31 ` poza
2018-06-20 17:26 ` [PATCH v2 0/5] Improve Broadcom PAXC support Ray Jui
2018-06-21 16:48 ` Lorenzo Pieralisi
2018-06-21 18:22 ` Ray Jui
2018-07-04 5:02 ` Ray Jui
2018-07-06 16:20 ` Lorenzo Pieralisi
2018-07-06 22:47 ` Ray Jui
2018-07-09 17:22 ` Lorenzo Pieralisi
2018-07-09 17:29 ` Ray Jui
2018-07-13 13:05 ` Lorenzo Pieralisi
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=2f545a86aa5433526b17071d64f68e50@codeaurora.org \
--to=poza@codeaurora.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci-owner@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=ray.jui@broadcom.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