- Request IRQF_ONESHOT for 'dra7xx-pcie-main' IRQ since the primary handler
  is NULL (Siddharth Vadapalli)

- Handle IRQ request errors during root port and endpoint probe (Siddharth
  Vadapalli)

* pci/controller/dra7xx:
  PCI: dra7xx: Fix error handling when IRQ request fails in probe
  PCI: dra7xx: Fix threaded IRQ request for "dra7xx-pcie-main" IRQ

- Drop excess cdns_pcie_rc.dev kerneldoc description (Bjorn Helgaas)

* pci/controller/cadence:
  PCI: cadence: Drop excess cdns_pcie_rc.dev kerneldoc description

- Change DT binding maintainer to Jim Quinlan (Jim Quinlan)

- Add DT binding maxItems for reset controllers (Jim Quinlan)

- Refactor .probe() error handling (Jim Quinlan)

- Use the 'bridge' reset method if described in the DT (Jim Quinlan)

- Use the 'swinit' reset method if described in the DT (Jim Quinlan)

- Add SoC-specific HARD_DEBUG, INTR2_CPU_BASE register offsets (Jim
  Quinlan)

- Drop unused RGR1_SW_INIT_1_INIT_MASK, RGR1_SW_INIT_1_INIT_SHIFT offsets
  (Jim Quinlan)

- Add 'has_phy' so the existence of a 'rescal' reset controller doesn't
  imply software control of it (Jim Quinlan)

- Add support for many inbound DMA windows (Jim Quinlan)

- Check return values of all reset_control_*() calls (Jim Quinlan)

- Rename SoC 'type' to 'soc_base' express the fact that SoCs come in
  families of multiple similar devices (Jim Quinlan)

- Add Broadcom 7712 DT description and driver support (Jim Quinlan)

- Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings for
  maintainability (Bjorn Helgaas)

* pci/controller/brcmstb:
  PCI: brcmstb: Sort enums, pcie_offsets[], pcie_cfg_data, .compatible strings
  PCI: brcmstb: Enable 7712 SoCs
  PCI: brcmstb: Change field name from 'type' to 'soc_base'
  PCI: brcmstb: Check return value of all reset_control_* calls
  PCI: brcmstb: Refactor for chips with many regular inbound windows
  PCI: brcmstb: Don't conflate the reset rescal with PHY ctrl
  PCI: brcmstb: Remove two unused constants from driver
  PCI: brcmstb: PCI: brcmstb: Make HARD_DEBUG, INTR2_CPU_BASE offsets SoC-specific
  PCI: brcmstb: Use swinit reset if available
  PCI: brcmstb: Use bridge reset if available
  PCI: brcmstb: Use common error handling code in brcm_pcie_probe()
  dt-bindings: PCI: brcm,stb-pcie: Add 7712 SoC description
  dt-bindings: PCI: brcm,stb-pcie: Use maxItems for reset controllers
  dt-bindings: PCI: brcm,stb-pcie: Change brcmstb maintainer and cleanup

- Replace TLP_REQ_ID() with macro PCI_DEVID(), which does the same thing
  and is what other drivers use (Jinjie Ruan)

* pci/controller/altera:
  PCI: altera: Replace TLP_REQ_ID() with macro PCI_DEVID()

- Add MSI_FLAG_NO_AFFINITY flag for devices that mux MSIs onto a single IRQ
  line and cannot set the affinity of each MSI to a specific CPU core
  (Marek Vasut)

- Use MSI_FLAG_NO_AFFINITY and remove unnecessary .irq_set_affinity()
  implementations in aardvark, altera, brcmstb, dwc, mediatek-gen3,
  mediatek, mobiveil, plda, rcar, tegra, vmd, xilinx-nwl, xilinx-xdma, and
  xilinx drivers to avoid "IRQ: set affinity failed" warnings (Marek Vasut)

* pci/controller/affinity:
  PCI: xilinx: Silence 'set affinity failed' warning
  PCI: xilinx-xdma: Silence 'set affinity failed' warning
  PCI: xilinx-nwl: Silence 'set affinity failed' warning
  PCI: vmd: Silence 'set affinity failed' warning
  PCI: tegra: Silence 'set affinity failed' warning
  PCI: rcar-host: Silence 'set affinity failed' warning
  PCI: plda: Silence 'set affinity failed' warning
  PCI: mobiveil: Silence 'set affinity failed' warning
  PCI: mediatek: Silence 'set affinity failed' warning
  PCI: mediatek-gen3: Silence 'set affinity failed' warning
  PCI: dwc: Silence 'set affinity failed' warning
  PCI: brcmstb: Silence 'set affinity failed' warning
  PCI: altera-msi: Silence 'set affinity failed' warning
  PCI: aardvark: Silence 'set affinity failed' warning
  genirq/msi: Silence 'set affinity failed' warning

- Fix enum pci_epc_bar_type kerneldoc (Bjorn Helgaas)

* pci/controller/endpoint:
  PCI: endpoint: Fix enum pci_epc_bar_type kerneldoc

- Drop minItems and maxItems from ranges in PCI generic host binding since
  host bridges may have several MMIO and I/O port apertures (Frank Li)

- Add kirin, rcar-gen2, uniphier DT binding top-level constraints for
  clocks (Krzysztof Kozlowski)

- Replace layerscape-pcie DT binding compatible fsl,lx2160a-pcie with
  fsl,lx2160ar2-pcie (Frank Li)

- Add layerscape-pcie DT binding deprecated 'num-viewport' property to
  address a DT checker warning (Frank Li)

- Change layerscape-pcie DT binding 'fsl,pcie-scfg' to phandle-array (Frank
  Li)

- Update qcom,pcie-sc7280 DT binding with eight interrupts (Rayyan Ansari)

- Convert altera DT bindings from text to YAML (Matthew Gerlach)

- Add imx6q-pcie 'dbi2' and 'atu' reg-names for i.MX8M Endpoints (Richard
  Zhu)

- Add back qcom 'vddpe-3v3-supply', which was incorrectly removed earlier
  (Johan Hovold)

* pci/dt-bindings:
  dt-bindings: PCI: qcom: Allow 'vddpe-3v3-supply' again
  dt-bindings: PCI: imx6q-pcie: Add reg-name "dbi2" and "atu" for i.MX8M PCIe Endpoint
  dt-bindings: PCI: altera: msi: Convert to YAML
  dt-bindings: PCI: altera: Convert to YAML
  dt-bindings: PCI: qcom,pcie-sc7280: Update bindings adding eight interrupts
  dt-bindings: PCI: layerscape-pci: Change property 'fsl,pcie-scfg' type
  dt-bindings: PCI: layerscape-pci: Add deprecated property 'num-viewport'
  dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with fsl,lx2160ar2-pcie
  dt-bindings: PCI: socionext,uniphier-pcie-ep: Add top-level constraints
  dt-bindings: PCI: renesas,pci-rcar-gen2: Add top-level constraints
  dt-bindings: PCI: hisilicon,kirin-pcie: Add top-level constraints
  dt-bindings: PCI: host-generic-pci: Drop minItems and maxItems of ranges

- Add ARCH_PCI_DEV_GROUPS so s390 can add its own attribute_groups without
  having to stomp on the core's pdev->dev.groups (Lukas Wunner)

* pci/sysfs:
  s390/pci: Stop usurping pdev->dev.groups

- Wait for each level of downstream bus, not just the first, to become
  accessible before restoring devices on that bus (Ilpo Järvinen)

* pci/reset:
  PCI: Wait for Link before restoring Downstream Buses

- Add pwrctl support for ATH11K inside the WCN6855 package (Konrad Dybcio)

* pci/pwrctl:
  PCI/pwrctl: Add WCN6855 support

- Initialize leds class earlier (with an unfortunate Makefile ordering
  change) so the PCI NPEM driver can use it (Mariusz Tkaczyk)

- Add Native PCIe Enclosure Management (NPEM) support for sysfs control of
  NVMe RAID storage indicators (ok/fail/locate/rebuild/etc) (Mariusz
  Tkaczyk)

- Add support for the ACPI _DSM PCIe SSD status LED management, which is
  functionally similar to NPEM but mediated by platform firmware (Mariusz
  Tkaczyk)

* pci/npem:
  PCI/NPEM: Add _DSM PCIe SSD status LED management
  PCI/NPEM: Add Native PCIe Enclosure Management support
  leds: Init leds class earlier

- Add function 0 DMA alias quirk for Glenfly Arise audio function, which
  uses the function 0 Requester ID (WangYuli)

* pci/iommu:
  PCI: Add function 0 DMA alias quirk for Glenfly Arise chip

- Remove unnecessary hpc_ops struct from shpchp (ngn)

- Check for PCI_POSSIBLE_ERROR(), not 0xffffffff, in cpqphp (weiyufeng)

* pci/hotplug:
  PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI: shpchp: Remove hpc_ops

- Clear LBMS bit after a manual link retrain so we don't try to retrain a
  link when there's no downstream device anymore (Maciej W. Rozycki)

- Revert to the original link speed after retraining fails instead of
  leaving it restricted to 2.5GT/s, so a future device has a chance to use
  higher speeds (Maciej W. Rozycki)

- Correct interpretation of pcie_retrain_link() return status and update it
  to return 0/errno instead of true/false (Maciej W.  Rozycki)

* pci/enumeration:
  PCI: Use an error code with PCIe failed link retraining
  PCI: Correct error reporting with PCIe failed link retraining
  PCI: Revert to the original speed after PCIe failed link retraining
  PCI: Clear the LBMS bit after a link retrain

- Export pcim_request_region(), a managed counterpart of
  pci_request_region(), for use by drivers (Philipp Stanner)

- Request the PCI BAR used by xboxvideo (Philipp Stanner)

- Export pcim_iomap_region() and deprecate pcim_iomap_regions() (Philipp
  Stanner)

- Request and map drm/ast BARs with pcim_iomap_region() (Philipp Stanner)

* pci/devres:
  drm/ast: Request PCI BAR with devres
  PCI: Deprecate pcim_iomap_regions() in favor of pcim_iomap_region()
  drm/vboxvideo: Add PCI region request
  PCI: Make pcim_request_region() a public function

- Wait for device readiness after reset by polling Vendor ID and looking
  for Configuration RRS instead of polling the Command register and looking
  for non-error completions (Bjorn Helgaas)

- Fix an aardvark issue with emulating Configuration RRS for two-byte reads
  of Vendor ID; previously it only worked for four-byte reads (Bjorn
  Helgaas)

- Rename CRS Completion Status to RRS to match spec usage (Bjorn Helgaas)

* pci/crs:
  PCI: Rename CRS Completion Status to RRS
  PCI: aardvark: Correct Configuration RRS checking
  PCI: Wait for device readiness with Configuration RRS

- Use PCI_DEVID() macro in aer_inject() instead of open-coding it (Jinjie
  Ruan)

* pci/aer:
  PCI/AER: Use PCI_DEVID() macro in aer_inject()

Commit 756485bf ("dt-bindings: PCI: qcom,pcie-sc7280: Move SC7280 to
dedicated schema") incorrectly removed 'vddpe-3v3-supply' from the
bindings, which results in DT checker warnings like:

  arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-dora.dtb: pcie@600000: Unevaluated properties are not allowed ('vddpe-3v3-supply' was unexpected)
  from schema $id: http://devicetree.org/schemas/pci/qcom,pcie.yaml#

Note that this property has been part of the Qualcomm PCIe bindings since
2018 and would need to be deprecated rather than simply removed if there is
a desire to replace it with 'vpcie3v3' which is used for some non-Qualcomm
controllers.

Link: https://lore.kernel.org/lkml/Zp_LPixNnh-2Fy5N@hovoldconsulting.com/
Fixes: 756485bf ("dt-bindings: PCI: qcom,pcie-sc7280: Move SC7280 to dedicated schema")
Link: https://lore.kernel.org/r/20240723151328.684-1-johan+linaro@kernel.orgSigned-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Commit d4c7d1a0 ("PCI: dwc: dra7xx: Push request_irq()
call to the bottom of probe") moved the IRQ request for
"dra7xx-pcie-main" towards the end of dra7xx_pcie_probe().

However, the error handling does not take into account the
initialization performed by either dra7xx_add_pcie_port() or
dra7xx_add_pcie_ep(), depending on the mode of operation.

Fix the error handling to address this.

Fixes: d4c7d1a0 ("PCI: dwc: dra7xx: Push request_irq() call to the bottom of probe")
Link: https://lore.kernel.org/linux-pci/20240827122422.985547-3-s-vadapalli@ti.comTested-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org

Commit da87d35a ("PCI: dra7xx: Use threaded IRQ handler for
"dra7xx-pcie-main" IRQ") switched from devm_request_irq() to
devm_request_threaded_irq() for the "dra7xx-pcie-main" interrupt.

Since the primary handler was set to NULL, the "IRQF_ONESHOT" flag
should have also been set. Fix this.

Fixes: da87d35a ("PCI: dra7xx: Use threaded IRQ handler for "dra7xx-pcie-main" IRQ")
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/linux-pci/20240827122422.985547-2-s-vadapalli@ti.comReported-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: stable@vger.kernel.org

Add reg-name: "dbi2", "atu" for i.MX8M PCIe Endpoint.

For i.MX8M PCIe EP, the dbi2 and atu addresses are pre-defined in the
driver. This method is not good.

In commit b7d67c61 ("PCI: imx6: Add iMX95 Endpoint (EP) support"),
Frank suggests to fetch the dbi2 and atu from DT directly. This commit is
preparation to do that for i.MX8M PCIe EP.

These changes wouldn't break driver function. When "dbi2" and "atu"
properties are present, i.MX PCIe driver would fetch the according base
addresses from DT directly. If only two reg properties are provided, i.MX
PCIe driver would fall back to the old method.

Link: https://lore.kernel.org/linux-pci/1723534943-28499-2-git-send-email-hongxing.zhu@nxp.comSigned-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Convert the devicetree bindings for the Altera PCIe MSI controller
from text to YAML.

Link: https://lore.kernel.org/linux-pci/20240717181756.2177553-1-matthew.gerlach@linux.intel.comSigned-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
[kwilczynski: remove unused msi0 label]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

PCIe r6.0 changed the abbreviation for "Configuration Request Retry Status"
Completion Status from "CRS" to "RRS" and uses the terminology of
"Configuration RRS Software Visibility" instead of "CRS Software
Visibility".

Align the Linux usage with the r6.0 spec language.  No functional change
intended.

It's confusing to make this change, but I think "RRS" *is* a better
abbreviation because it was easy to interpret "CRS" as "Completion Retry
Status", which really didn't make any sense.

Link: https://lore.kernel.org/r/20240827234848.4429-4-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>

Per PCIe r6.0, sec 2.3.2, when a Root Complex handles a Completion with
Request Retry Status for a Configuration Read Request that includes both
bytes of the Vendor ID field, it must complete the Request to the host by
returning 0001h for the Vendor ID and all 1's for any additional bytes.

Previously we only returned the 0001h Vendor ID value if we got an RRS
completion for reads of exactly 4 bytes.  A read of 2 bytes would not
qualify, although the spec says it should.

Check for reads of 2 or more bytes including the Vendor ID.

I don't think this will fix any observable problems because RRS only
applies to the first config reads after reset, and those are all currently
dword (4-byte) reads.

Link: https://lore.kernel.org/r/20240827234848.4429-3-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>

After a device reset, delays are required before the device can
successfully complete config accesses.  PCIe r6.0, sec 6.6, specifies some
delays required before software can perform config accesses.  Devices that
require more time after those delays may respond to config accesses with
Configuration Request Retry Status (RRS) completions.

Callers of pci_dev_wait() are responsible for delays until the device can
respond to config accesses.  pci_dev_wait() waits any additional time until
the device can successfully complete config accesses.

Reading config space of devices that are not present or not ready typically
returns ~0 (PCI_ERROR_RESPONSE).  Previously we polled the Command register
until we got a value other than ~0.  This is sometimes a problem because
Root Complex handling of RRS completions may include several retries and
implementation-specific behavior that is invisible to software (see sec
2.3.2), so the exponential backoff in pci_dev_wait() may not work as
intended.

Linux enables Configuration RRS Software Visibility on all Root Ports that
support it.  If it is enabled, read the Vendor ID instead of the Command
register.  RRS completions cause immediate return of the 0x0001 reserved
Vendor ID value, so the pci_dev_wait() backoff works correctly.

When a read of Vendor ID eventually completes successfully by returning a
non-0x0001 value (the Vendor ID or 0xffff for VFs), the device should be
initialized and ready to respond to config requests.

For conventional PCI devices or devices below Root Ports that don't support
Configuration RRS Software Visibility, poll the Command register as before.

This was developed independently, but is very similar to Stanislav
Spassov's previous work at
https://lore.kernel.org/linux-pci/20200223122057.6504-1-stanspas@amazon.com

Link: https://lore.kernel.org/r/20240827234848.4429-2-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Duc Dang <ducdang@google.com>

Sort enum pcie_soc_base values.

Rename pcie_offsets_bmips_7425[] to pcie_offsets_bcm7425[] to match BCM7425
pcie_soc_base enum, bcm7425_cfg, and "brcm,bcm7425-pcie" .compatible
string.

Rename pcie_offset_bcm7278[] to pcie_offsets_bcm7278[] to match other
"pcie_offsets" names.

Rename pcie_offset_bcm7712[] to pcie_offsets_bcm7712[] to match other
"pcie_offsets" names.

Sort pcie_offsets_*[] by SoC name, move them all together, indent values
for easy reading.

Sort pcie_cfg_data structs by SoC name.

Sort .compatible strings by SoC name.

No functional change intended.

Link: https://lore.kernel.org/r/20240902205456.227409-1-helgaas@kernel.orgSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>

Given how the call place in pcie_wait_for_link_delay() got structured now,
and that pcie_retrain_link() returns a potentially useful error code,
convert pcie_failed_link_retrain() to return an error code rather than a
boolean status, fixing handling at the call site mentioned.  Update the
other call site accordingly.

Fixes: 1abb4739 ("Merge branch 'pci/enumeration'")
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091156530.61955@angie.orcam.me.ukReported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.5+

Only return successful completion status from pcie_failed_link_retrain() if
retraining has actually been done, preventing excessive delays from being
triggered at call sites in a hope that communication will finally be
established with the downstream device where in fact nothing has been done
about the link in question that would justify such a hope.

Fixes: a89c8224 ("PCI: Work around PCIe link training failures")
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091133260.61955@angie.orcam.me.ukReported-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/aa2d1c4e-9961-d54a-00c7-ddf8e858a9b0@linux.intel.com/Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.5+

When `pcie_failed_link_retrain' has failed to retrain the link by hand
it leaves the link speed restricted to 2.5GT/s, which will then affect
any device that has been plugged in later on, which may not suffer from
the problem that caused the speed restriction to have been attempted.
Consequently such a downstream device will suffer from an unnecessary
communication throughput limitation and therefore performance loss.

Remove the speed restriction then and revert the Link Control 2 register
to its original state if link retraining with the speed restriction in
place has failed.  Retrain the link again afterwards so as to remove any
residual state, waiting on LT rather than DLLLA to avoid an excessive
delay and ignoring the result as this training is supposed to fail
anyway.

Fixes: a89c8224 ("PCI: Work around PCIe link training failures")
Link: https://lore.kernel.org/linux-pci/alpine.DEB.2.21.2408251412590.30766@angie.orcam.me.ukReported-by: Matthew W Carlis <mattc@purestorage.com>
Link: https://lore.kernel.org/r/20240806000659.30859-1-mattc@purestorage.com/
Link: https://lore.kernel.org/r/20240722193407.23255-1-mattc@purestorage.com/Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v6.5+

The LBMS bit, where implemented, is set by hardware either in response
to the completion of retraining caused by writing 1 to the Retrain Link
bit or whenever hardware has changed the link speed or width in attempt
to correct unreliable link operation.  It is never cleared by hardware
other than by software writing 1 to the bit position in the Link Status
register and we never do such a write.

We currently have two places, namely apply_bad_link_workaround() and
pcie_failed_link_retrain() in drivers/pci/controller/dwc/pcie-tegra194.c
and drivers/pci/quirks.c respectively where we check the state of the LBMS
bit and neither is interested in the state of the bit resulting from the
completion of retraining, both check for a link fault.

And in particular pcie_failed_link_retrain() causes issues consequently, by
trying to retrain a link where there's no downstream device anymore and the
state of 1 in the LBMS bit has been retained from when there was a device
downstream that has since been removed.

Clear the LBMS bit then at the conclusion of pcie_retrain_link(), so that
we have a single place that controls it and that our code can track link
speed or width changes resulting from unreliable link operation.

Fixes: a89c8224 ("PCI: Work around PCIe link training failures")
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2408091133140.61955@angie.orcam.me.ukReported-by: Matthew W Carlis <mattc@purestorage.com>
Link: https://lore.kernel.org/r/20240806000659.30859-1-mattc@purestorage.com/
Link: https://lore.kernel.org/r/20240722193407.23255-1-mattc@purestorage.com/Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Cc: <stable@vger.kernel.org> # v6.5+

The Broadcom STB 7712 is the sibling chip of the RPi 5 (2712). It has
one PCIe controller with a single port, supports gen2 and one lane only.

The current revision of the chip is "C0" or "C1".

Link: https://lore.kernel.org/linux-pci/20240815225731.40276-14-james.quinlan@broadcom.comSigned-off-by: Jim Quinlan <james.quinlan@broadcom.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Stanimir Varbanov <svarbanov@suse.de>

The 'type' field used in the driver to discern SoC differences is
confusing; change it to the more apt 'soc_base'.

The 'base' is because some SoCs have the same characteristics as
previous SoCs so it is convenient to classify them in the same group.

Link: https://lore.kernel.org/linux-pci/20240815225731.40276-13-james.quinlan@broadcom.comSigned-off-by: Jim Quinlan <james.quinlan@broadcom.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Always check the return value for invocations of reset_control_xxx() and
propagate the error to the next level.

Although the current functions in reset-brcmstb.c cannot fail, this may
someday change.

Link: https://lore.kernel.org/linux-pci/20240815225731.40276-12-james.quinlan@broadcom.comSigned-off-by: Jim Quinlan <james.quinlan@broadcom.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Stanimir Varbanov <svarbanov@suse.de>

Provide support for new chips with multiple inbound windows while
keeping the legacy support for the older chips.

In existing chips there are three inbound windows with fixed purposes:
the first was for mapping SoC internal registers, the second was for
memory, and the third was for memory but with the endian swapped.
Typically, only one window was used.

Complicating the inbound window usage was the fact that the PCIe HW
would do a baroque internal mapping of system memory, and concatenate
the regions of multiple memory controllers.

Newer chips such as the 7712 and Cable Modem SoCs take a step forward
and drop the internal mapping while providing for multiple inbound
windows. This works in concert with the dma-ranges property, where each
provided range becomes an inbound window.

Link: https://lore.kernel.org/linux-pci/20240815225731.40276-11-james.quinlan@broadcom.comCo-developed-by: Riyan Dhiman <riyandhiman14@gmail.com>
Signed-off-by: Riyan Dhiman <riyandhiman14@gmail.com>
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
[kwilczynski: commit log, wrap code comments to 80 columns]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Stanimir Varbanov <svarbanov@suse.de>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

The PCIe SSD Status LED Management _DSM defined in PCI Firmware Spec r3.3
sec 4.7 provides a way to manage LEDs via ACPI.

The design is similar to NPEM defined in PCIe Base Specification r6.1 sec
6.28:

  - Both standards are indication oriented,

  - _DSM supported bits correspond to NPEM capability register bits,

  - _DSM control bits correspond to NPEM control register bits.

_DSM does not support enclosure-specific indications or the special NPEM
commands NPEM_ENABLE and NPEM_RESET.

_DSM is implemented as a second backend in NPEM driver. The backend used is
logged with info priority. The same sysfs interface is used for both NPEM
and _DSM.

According to spec, _DSM has higher priority, and availability  of _DSM in
not limited to devices with NPEM support.

The Dell implementation of DSM uses acpi ipmi, which may not be available
immediately (in fact it may take up to 10s for this interface to be
available). It can determine if DSM is supported (GET_SUPPORTED_STATES_DSM
is working) but it cannot serve GET_STATE_DSM or SET_STATE_DSM commands in
this time.

From userspace application perspective (primarily configured by systemd
service) it is better to have not working but configured interface rather
than have it available after few seconds.

For that reason, npem->active_indications cache is now loaded lazily, i.e.
any GET or SET request want cache to be updated if it is not done yet.

Link: https://lore.kernel.org/r/20240904104848.23480-4-mariusz.tkaczyk@linux.intel.comSuggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

The TLP_REQ_ID's function is same as current PCI_DEVID()
macro, replace it.

No functional changes intended.

Link: https://lore.kernel.org/linux-pci/20240828104202.3683491-1-ruanjinjie@huawei.comSigned-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
LEDs in storage enclosures. NPEM is indication oriented and it does not
give direct access to LEDs. Although each indication *could* represent an
individual LED, multiple indications could also be represented as a single,
multi-color LED or a single LED blinking in a specific interval.  The
specification leaves that open.

Each enabled indication (capability register bit on) is represented as a
ledclass_dev which can be controlled through sysfs. For every ledclass
device only 2 brightness states are allowed: LED_ON (1) or LED_OFF (0).
This corresponds to the NPEM control register (Indication bit on/off).

Ledclass devices appear in sysfs as child devices (subdirectory) of PCI
device which has an NPEM Extended Capability and indication is enabled in
NPEM capability register. For example, these are LEDs created for pcieport
"10000:02:05.0" on my setup:

  leds/
  ├── 10000:02:05.0:enclosure:fail
  ├── 10000:02:05.0:enclosure:locate
  ├── 10000:02:05.0:enclosure:ok
  └── 10000:02:05.0:enclosure:rebuild

They can be also found in "/sys/class/leds" directory. The parent PCIe
device domain/bus/device/function address is used to guarantee uniqueness
across leds subsystem.

To enable/disable a "fail" indication, the "brightness" file can be edited:

  echo 1 > ./leds/10000:02:05.0:enclosure:fail/brightness
  echo 0 > ./leds/10000:02:05.0:enclosure:fail/brightness

PCIe r6.1, sec 7.9.19.2 defines the possible indications.

Multiple indications for same parent PCIe device can conflict and hardware
may update them when processing new request. To avoid issues, driver
refresh all indications by reading back control register.

This driver expects to be the exclusive NPEM extended capability manager.
It waits up to 1 second after imposing new request, it doesn't verify if
controller is busy before write, and it assumes the mutex lock gives
protection from concurrent updates.

If _DSM LED management is available, we assume the platform may be using
NPEM for its own purposes (see PCI Firmware Spec r3.3 sec 4.7), so the
driver does not use NPEM. A future patch will add _DSM support; an info
message notes whether NPEM or _DSM is being used.

NPEM is a PCIe extended capability so it should be registered in
pcie_init_capabilities() but it is not possible due to LED dependency.  The
parent pci_device must be added earlier for led_classdev_register() to be
successful. NPEM does not require configuration on kernel side, so it is
safe to register LED devices later.

Link: https://lore.kernel.org/r/20240904104848.23480-3-mariusz.tkaczyk@linux.intel.comSuggested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

NPEM driver will require leds class, there is an init-order conflict.
Make sure that LEDs initialization happens first and add comment.

Link: https://lore.kernel.org/r/20240904104848.23480-2-mariusz.tkaczyk@linux.intel.comSuggested-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

Convert the devicetree bindings for the Altera Root Port PCIe controller
from text to YAML.

While at it, update the entries in the interrupt-map field to have the
correct number of address cells for the interrupt parent.

Link: https://lore.kernel.org/linux-pci/20240702162652.1349121-1-matthew.gerlach@linux.intel.comSigned-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Previous commit to this bindings, commit 756485bf ("dt-bindings:
PCI: qcom,pcie-sc7280: Move SC7280 to dedicated schema"), updated the
bindings to specify one interrupt only, as the devicetree at that time
did not describe the hardware fully.

The devicetree for SC7280 now specifies eight interrupts, following the
commit b8ba66b4 ("arm64: dts: qcom: sc7280: Add additional MSI
interrupts").

Thus, update the bindings to reflect this.

Link: https://lore.kernel.org/linux-pci/20240722-sc7280-pcie-interrupts-v2-1-a5414d3dbc64@linaro.orgSigned-off-by: Rayyan Ansari <rayyan.ansari@linaro.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>