- 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>

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>

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 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>

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>

The fsl,pcie-scfg requires an argument when there are more than one PCIe
instances.

Thus, change it to the phandle-array type and use items to describe
what each field means.

This also fixes the following warning:

  arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dtb: pcie@3400000: fsl,pcie-scfg:0: [22, 0] is too long from schema $id: http://devicetree.org/schemas/pci/fsl,layerscape-pcie.yaml#

Link: https://lore.kernel.org/linux-pci/20240701221612.2112668-1-Frank.Li@nxp.comSigned-off-by: Frank Li <Frank.Li@nxp.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>

Copy the 'num-viewport' property from snps,dw-pcie-common.yaml to
fsl,layerscape-pcie.yaml to address the following warning:

  /arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dtb: pcie@3400000: Unevaluated properties are not allowed ('num-viewport' was unexpected)

This is necessary due to historical reasons where fsl,layerscape-pcie.yaml
does not directly reference snps,dw-pcie-common.yaml.

Link: https://lore.kernel.org/linux-pci/20240823185855.776904-1-Frank.Li@nxp.comSigned-off-by: Frank Li <Frank.Li@nxp.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>

The fsl,lx2160a-pcie compatible is used for mobivel according to the
Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt file.

Whereas the fsl,layerscape-pcie is used for DesignWare PCIe controller binding.

So change it to fsl,lx2160ar2-pcie and allow a fall back to fsl,ls2088a-pcie.

While at it, sort compatible string.

Fixes: 24cd7ecb ("dt-bindings: PCI: layerscape-pci: Convert to YAML format")
Link: https://lore.kernel.org/linux-pci/20240826-2160r2-v1-1-106340d538d6@nxp.comSigned-off-by: Frank Li <Frank.Li@nxp.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".

Add missing top-level constraints for clock-names and reset-names.

Link: https://lore.kernel.org/linux-pci/20240818172843.121787-3-krzysztof.kozlowski@linaro.orgSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".

Add missing top-level constraints for clocks and clock-names.

Link: https://lore.kernel.org/linux-pci/20240818172843.121787-2-krzysztof.kozlowski@linaro.orgSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:".

Add missing top-level constraints for clock-names and reset-names.

Link: https://lore.kernel.org/linux-pci/20240818172843.121787-1-krzysztof.kozlowski@linaro.orgSigned-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

e01c9797 ("PCI: endpoint: Clean up hardware description for BARs")
added enum pci_epc_bar_type with incomplete kerneldoc.  Add the missing
piece.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

The PCI_DEVID() macro can be used instead of open-coding it.

No functional changes intended.

Link: https://lore.kernel.org/linux-pci/20240829022435.4145181-1-ruanjinjie@huawei.comSigned-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>

Add DMA support for audio function of Glenfly Arise chip, which uses
Requester ID of function 0.

Link: https://lore.kernel.org/r/CA2BBD087345B6D1+20240823095708.3237375-1-wangyuli@uniontech.comSigned-off-by: SiyuLi <siyuli@glenfly.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
[bhelgaas: lower-case hex to match local code, drop unused Device IDs]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>

Add support for ATH11K inside the WCN6855 package to the power sequencing
PCI power control driver.

Link: https://lore.kernel.org/r/20240813191201.155123-1-brgl@bgdev.pl
[Bartosz: split Konrad's bigger patch, write the commit message]
Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Konrad Dybcio <konradybcio@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Konrad Dybcio <konradybcio@kernel.org>

__pci_reset_bus() calls pci_bridge_secondary_bus_reset() to perform the
reset and also waits for the Secondary Bus to become again accessible.
__pci_reset_bus() then calls pci_bus_restore_locked() that restores the PCI
devices connected to the bus, and if necessary, recursively restores also
the subordinate buses and their devices.

The logic in pci_bus_restore_locked() does not take into account that after
restoring a device on one level, there might be another Link Downstream
that can only start to come up after restore has been performed for its
Downstream Port device. That is, the Link may require additional wait until
it becomes accessible.

Similarly, pci_slot_restore_locked() lacks wait.

Amend pci_bus_restore_locked() and pci_slot_restore_locked() to wait for
the Secondary Bus before recursively performing the restore of that bus.

Fixes: 090a3c53 ("PCI: Add pci_reset_slot() and pci_reset_bus()")
Link: https://lore.kernel.org/r/20240808121708.2523-1-ilpo.jarvinen@linux.intel.comSigned-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

ast currently ioremaps two PCI BARs using pcim_iomap(). It does not perform
a request on the regions, however, which would make the driver a bit more
robust.

PCI now offers pcim_iomap_region(), a managed function which both requests
and ioremaps a BAR.

Replace pcim_iomap() with pcim_iomap_region().
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20240807083018.8734-4-pstanner@redhat.comSigned-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Dave Airlie <airlied@redhat.com>