kernel/drivers/pci/controller/pcie-brcmstb.c, branch linux-rolling-stable

PCI: brcmstb: Add panic/die handler to driver

2025-11-13T16:47:16Z

Most PCIe HW returns 0xffffffff for failed reads on PCIe, but by default Broadcom's STB PCIe controller effects an abort. Some SoCs -- 7216 and its descendants -- have new HW that identifies error details. Add a simple handler to print diagnostic info in case the PCIe controller was the cause of the abort. Unfortunately, an abort still occurs. Read the error registers only when the PCIe bridge is active and the PCIe registers are accessible. Otherwise, a "die" event caused by something other than PCIe could cause an abort if the PCIe "die" handler tried to access registers when the bridge is off. Example error output: brcm-pcie 8b20000.pcie: Error: Mem Acc: 32bit, read, @0x38000000 brcm-pcie 8b20000.pcie: Type: TO=0 Abt=0 UnspReq=1 AccDsble=0 BadAddr=0 Signed-off-by: Jim Quinlan Signed-off-by: Bjorn Helgaas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251029193616.3670003-3-james.quinlan@broadcom.com

PCI: brcmstb: Add a way to indicate if PCIe bridge is active

2025-11-13T16:45:28Z

In a future commit, a new handler will be introduced that in part does reads and writes to some of the PCIe registers. When this handler is invoked, it is paramount that it does not do these register accesses when the PCIe bridge is inactive, as this will cause CPU abort errors. To solve this we keep a spinlock that guards a variable which indicates whether the bridge is on or off. When the bridge is on, access of the PCIe HW registers may proceed. Since there are multiple ways to reset the bridge, we introduce a general function to obtain the spinlock, call the specific function that is used for the specific SoC, sets the bridge active indicator variable, and releases the spinlock. Signed-off-by: Jim Quinlan Signed-off-by: Bjorn Helgaas Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20251029193616.3670003-2-james.quinlan@broadcom.com

PCI: brcmstb: Fix disabling L0s capability

2025-10-28T18:04:42Z

caab002d5069 ("PCI: brcmstb: Disable L0s component of ASPM if requested") set PCI_EXP_LNKCAP_ASPM_L1 and (optionally) PCI_EXP_LNKCAP_ASPM_L0S in PCI_EXP_LNKCAP (aka PCIE_RC_CFG_PRIV1_LINK_CAPABILITY in brcmstb). But instead of using PCI_EXP_LNKCAP_ASPM_L1 and PCI_EXP_LNKCAP_ASPM_L0S directly, it used PCIE_LINK_STATE_L1 and PCIE_LINK_STATE_L0S, which are Linux-created values that only coincidentally matched the PCIe spec. b478e162f227 ("PCI/ASPM: Consolidate link state defines") later changed them so they no longer matched the PCIe spec, so the bits ended up in the wrong place in PCI_EXP_LNKCAP. Use PCI_EXP_LNKCAP_ASPM_L0S to clear L0s support when there's an 'aspm-no-l0s' property. Rely on brcmstb hardware to advertise L0s and/or L1 support otherwise. Fixes: caab002d5069 ("PCI: brcmstb: Disable L0s component of ASPM if requested") Reported-by: Bjorn Helgaas Closes: https://lore.kernel.org/linux-pci/20250925194424.GA2197200@bhelgaas Signed-off-by: Jim Quinlan [mani: reworded subject and description, added closes tag and CCed stable] Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Florian Fainelli Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251003170436.1446030-1-james.quinlan@broadcom.com

Merge branch 'pci/misc'

2025-07-31T21:12:19Z

- Remove resolved hotplug TODO item (Guilherme Giacomo Simoes) - Fix typos (Bjorn Helgaas) * pci/misc: PCI: Fix typos PCI: hotplug: Remove TODO about unused .get_power(), .hardware_test()

Merge branch 'pci/controller/brcmstb'

2025-07-31T21:12:05Z

- Add optional DT 'num-lanes' property and if present, use it to override the Maximum Link Width advertised in Link Capabilities (Jim Quinlan) * pci/controller/brcmstb: PCI: brcmstb: Replace open coded value with PCIE_T_RRS_READY_MS MAINTAINERS: Drop Nicolas from maintaining pcie-brcmstb PCI: brcmstb: Set MLW based on "num-lanes" DT property if present dt-bindings: PCI: brcm,stb-pcie: Add num-lanes property

PCI: brcmstb: Switch to msi_create_parent_irq_domain()

2025-07-24T21:24:15Z

Switch to msi_create_parent_irq_domain() from pci_msi_create_irq_domain() which was using legacy MSI domain setup. Signed-off-by: Nam Cao [mani: reworded commit message] Signed-off-by: Manivannan Sadhasivam [bhelgaas: rebase on dev_fwnode() conversion, drop fwnode local var] Signed-off-by: Bjorn Helgaas Reviewed-by: Thomas Gleixner Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/fa72703e06c2ee2c7554082c7152913eb0dd294f.1750858083.git.namcao@linutronix.de

PCI: Fix typos

2025-07-23T18:12:38Z

Fix typos. Signed-off-by: Bjorn Helgaas Acked-by: Thomas Gleixner Link: https://patch.msgid.link/20250722213743.2822761-1-helgaas@kernel.org

PCI: brcmstb: Replace open coded value with PCIE_T_RRS_READY_MS

2025-07-17T12:46:25Z

The delay that we are waiting on in brcm_pcie_start_link() is PCIE_T_RRS_READY_MS, use it. Signed-off-by: Florian Fainelli [mani: Removed the redundant comment] Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250624231923.990361-3-florian.fainelli@broadcom.com

PCI: brcmstb: Set MLW based on "num-lanes" DT property if present

2025-06-23T11:52:40Z

By default, the driver relies on the default hardware defined value for the Max Link Width (MLW) capability. But if the "num-lanes" DT property is present, assume that the chip's default capability information is incorrect or undesired, and use the specified value instead. Signed-off-by: Jim Quinlan [mani: reworded the description and comments] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20250530224035.41886-3-james.quinlan@broadcom.com

PCI: Switch to irq_domain_create_linear()

2025-05-16T19:06:10Z

irq_domain_add_linear() is going away as being obsolete now. Switch to the preferred irq_domain_create_linear(). That differs in the first parameter: It takes more generic struct fwnode_handle instead of struct device_node. Therefore, of_fwnode_handle() is added around the parameter. Note some of the users can likely use dev->fwnode directly instead of indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not guaranteed to be set for all, so this has to be investigated on case to case basis (by people who can actually test with the HW). [ tglx: Fix up subject prefix and convert the new instance in dwc/pcie-amd-mdb.c ] Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250319092951.37667-30-jirislaby@kernel.org