PCIe spec 5.0r1.0 section 2.2.6.2 implementation note, In configurations
where a Requester with 10-Bit Tag Requester capability needs to target
multiple Completers, one needs to ensure that the Requester sends 10-Bit
Tag Requests only to Completers that have 10-Bit Tag Completer capability.
So we enable 10-Bit Tag Requester for root port only when the devices
under the root port support 10-Bit Tag Completer.

Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>

Enable VF 10-Bit Tag Requester when it's upstream component support
10-bit Tag Completer.

Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>

10-Bit Tag capability, introduced in PCIe-4.0 increases the total Tag
field size from 8 bits to 10 bits.

For platforms where the RC supports 10-Bit Tag Completer capability,
it is highly recommended for platform firmware or operating software
that configures PCIe hierarchies to Set the 10-Bit Tag Requester Enable
bit automatically in Endpoints with 10-Bit Tag Requester capability. This
enables the important class of 10-Bit Tag capable adapters that send
Memory Read Requests only to host memory.

Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>

Add 10-Bit Tag register definitions for use in subsequen patches.
See the PCIe 5.0 spec section 7.5.3.15 and 9.3.3.2.

Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>

It will make sense to store the pcie_devcap2 value in the pci_dev
structure instead of reading Device Capabilities 2 Register multiple
times. Add pci_init_devcap2() to get the pcie_devcap2 value, then
use cached pcie_devcap2 in the needed place.

Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>

It will make sense to store the pcie_devcap value in the pci_dev
structure instead of reading Device Capabilities Register multiple
times. The fisrt place to use pcie_devcap is in set_pcie_port_type(),
get the pcie_devcap value here, then use cached pcie_devcap in the
needed place.

Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>

- Annotate __iomem pointer (Bjorn Helgaas)

- Fix kernel-doc comment (Krzysztof Wilczyński)

* remotes/lorenzo/pci/xgene:
  PCI: xgene: Fix a non-compliant kernel-doc
  PCI: xgene: Annotate __iomem pointer

- Fix host init during resume (Vidya Sagar)

- Add missing MODULE_DEVICE_TABLE for driver loading (Zou Wei)

* remotes/lorenzo/pci/tegra:
  PCI: tegra: Add missing MODULE_DEVICE_TABLE
  PCI: tegra: Fix host initialization during resume

- Removed unused readl and writel functions (Krzysztof Wilczyński)

* remotes/lorenzo/pci/mobiveil:
  PCI: mobiveil: Remove unused readl and writel functions

- Make struct event_descs static (Krzysztof Wilczyński)

* remotes/lorenzo/pci/microchip:
  PCI: microchip: Make the struct event_descs static

- Drop redundant error message from mtk_pcie_subsys_powerup() (Zhen Lei)

* remotes/lorenzo/pci/mediatek:
  PCI: mediatek: Remove redundant error printing in mtk_pcie_subsys_powerup()

- Fix race when removing device (Long Li)

- Remove unused bus device removal refcount/functions (Long Li)

* remotes/lorenzo/pci/hv:
  PCI: hv: Remove bus device removal unused refcount/functions
  PCI: hv: Fix a race condition when removing the device

- Rename PCI_IOSIZE, etc in ftpci100 to avoid macro name collisions (Randy
  Dunlap)

* remotes/lorenzo/pci/ftpci100:
  PCI: ftpci100: Rename macro name collision

- Drop redundant error message from imx6_pcie_probe() (Zhen Lei)

* remotes/lorenzo/pci/dwc:
  PCI: dwc/imx6: Remove redundant error printing in imx6_pcie_probe()

- Wait for previous PIO transfer to complete before starting a new one to
  avoid External Aborts (Pali Rohár)

* remotes/lorenzo/pci/aardvark:
  PCI: aardvark: Fix kernel panic during PIO transfer

- Clarify error message for unbound devices (Moritz Fischer)

* pci/virtualization:
  PCI/IOV: Clarify error message for unbound devices

- Fix dsm_label_utf16s_to_utf8s() buffer overrun (Krzysztof Wilczyński)

- Use sysfs_emit() and sysfs_emit_at() in "show" functions (Krzysztof
  Wilczyński)

- Fix 'resource_alignment' newline issues (Krzysztof Wilczyński)

- Add newline to 'devspec' sysfs file (Krzysztof Wilczyński)

* pci/sysfs:
  PCI/sysfs: Add 'devspec' newline
  PCI/sysfs: Fix 'resource_alignment' newline issues
  PCI/sysfs: Use sysfs_emit() and sysfs_emit_at() in "show" functions
  PCI/sysfs: Rely on lengths from scnprintf(), dsm_label_utf16s_to_utf8s()
  PCI/sysfs: Fix dsm_label_utf16s_to_utf8s() buffer overrun

- Coalesce host bridge apertures so we can allocate large BARs that cross
  contiguous apertures (Kai-Heng Feng)

* pci/resource:
  PCI: Coalesce host bridge contiguous apertures

- Return true/false (not 1/0) from bool functions (Yang Li)

* pci/misc:
  x86/pci: Return true/false (not 1/0) from bool functions

- Make domain/bus/dev/fn format in AER messages match pci_name() format
  (Yicong Yang)

* pci/error:
  Documentation: PCI: Fix typo in pci-error-recovery.rst
  PCI/AER: Use consistent format when printing PCI device

- Add a debug message on PCI device release (Niklas Schnelle)

* pci/enumeration:
  PCI: Print a debug message on PCI device release

Be more verbose to disambiguate the error case when trying to configure
SR-IOV with no driver bound vs. a driver that does not implement the
.sriov_configure() callback.

Link: https://lore.kernel.org/r/20210327175140.682708-1-mdf@kernel.org
Reported-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>

Trying to start a new PIO transfer by writing value 0 in PIO_START register
when previous transfer has not yet completed (which is indicated by value 1
in PIO_START) causes an External Abort on CPU, which results in kernel
panic:

    SError Interrupt on CPU0, code 0xbf000002 -- SError
    Kernel panic - not syncing: Asynchronous SError Interrupt

To prevent kernel panic, it is required to reject a new PIO transfer when
previous one has not finished yet.

If previous PIO transfer is not finished yet, the kernel may issue a new
PIO request only if the previous PIO transfer timed out.

In the past the root cause of this issue was incorrectly identified (as it
often happens during link retraining or after link down event) and special
hack was implemented in Trusted Firmware to catch all SError events in EL3,
to ignore errors with code 0xbf000002 and not forwarding any other errors
to kernel and instead throw panic from EL3 Trusted Firmware handler.

Links to discussion and patches about this issue:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

But the real cause was the fact that during link retraining or after link
down event the PIO transfer may take longer time, up to the 1.44s until it
times out. This increased probability that a new PIO transfer would be
issued by kernel while previous one has not finished yet.

After applying this change into the kernel, it is possible to revert the
mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.
Link: https://lore.kernel.org/r/20210608203655.31228-1-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Marek Behún <kabel@kernel.org>
Cc: stable@vger.kernel.org # 7fbcb5d ("PCI: aardvark: Don't rely on jiffies while holding spinlock")

Built-in graphics on HP EliteDesk 805 G6 doesn't work because graphics
can't get the BAR it needs:

  pci_bus 0000:00: root bus resource [mem 0x10020200000-0x100303fffff window]
  pci_bus 0000:00: root bus resource [mem 0x10030400000-0x100401fffff window]

  pci 0000:00:08.1:   bridge window [mem 0xd2000000-0xd23fffff]
  pci 0000:00:08.1:   bridge window [mem 0x10030000000-0x100401fffff 64bit pref]
  pci 0000:00:08.1: can't claim BAR 15 [mem 0x10030000000-0x100401fffff 64bit pref]: no compatible bridge window
  pci 0000:00:08.1: [mem 0x10030000000-0x100401fffff 64bit pref] clipped to [mem 0x10030000000-0x100303fffff 64bit pref]
  pci 0000:00:08.1:   bridge window [mem 0x10030000000-0x100303fffff 64bit pref]
  pci 0000:07:00.0: can't claim BAR 0 [mem 0x10030000000-0x1003fffffff 64bit pref]: no compatible bridge window
  pci 0000:07:00.0: can't claim BAR 2 [mem 0x10040000000-0x100401fffff 64bit pref]: no compatible bridge window

However, the root bus has two contiguous apertures that can contain the
child resource requested.

Coalesce contiguous apertures so we can allocate from the entire contiguous
region.

[bhelgaas: fold in https://lore.kernel.org/r/20210528170242.1564038-1-kai.heng.feng@canonical.com]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212013
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20210401131252.531935-1-kai.heng.feng@canonical.com
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

Previously, when the value of the "devspec" sysfs attribute was read from
the user space there was no newline present, and utilities such as "cat"
wouldn't display the result of the read correctly.

Append a newline character in the show() function to match other "devspec"
attributes.

Link: https://lore.kernel.org/r/20210603000112.703037-5-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

The value of the "resource_alignment" can be specified using a kernel
command-line argument ("pci=resource_alignment=") or through the
corresponding sysfs attribute under the /sys/bus/pci path.

Previously, when the value was set via the kernel command-line argument,
and then subsequently accessed through sysfs attribute, the value read back
was not correct:

  # grep -oE 'pci=resource_alignment.+' /proc/cmdline
  pci=resource_alignment=20@00:1f.2
  # cat /sys/bus/pci/resource_alignment
  20@00:1f.

This was also true when the value was set through the sysfs attribute
without including a trailing newline:

  # echo -n 20@00:1f.2 > /sys/bus/pci/resource_alignment
  # cat /sys/bus/pci/resource_alignment
  20@00:1f.

When it was set through the sysfs attribute *including* a newline,
reading it back worked as intended:

  # echo 20@00:1f.2 > /sys/bus/pci/resource_alignment
  # cat /sys/bus/pci/resource_alignment
  20@00:1f.2

To fix this inconsistency, append a trailing newline in the show() function
and strip the trailing line in the store() function if one is present.

Also, allow for the value previously set using either a command-line
argument or through the sysfs object to be cleared at run-time.

[bhelgaas: fold in kfree fix from
https://lore.kernel.org/linux-pci/20210604133230.983956-4-kw@linux.com]
Fixes: e499081 ("PCI: Force trailing new line to resource_alignment_param in sysfs")
Link: https://lore.kernel.org/r/20210603000112.703037-4-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

The sysfs_emit() and sysfs_emit_at() functions were introduced to make
it less ambiguous which function is preferred when writing to the output
buffer in a device attribute's "show" callback [1].

Convert the PCI sysfs object "show" functions from sprintf(), snprintf()
and scnprintf() to sysfs_emit() and sysfs_emit_at() accordingly, as the
latter is aware of the PAGE_SIZE buffer and correctly returns the number
of bytes written into the buffer.

No functional change intended.

[1] Documentation/filesystems/sysfs.rst

Related commit: ad025f8 ("PCI/sysfs: Use sysfs_emit() and
sysfs_emit_at() in "show" functions").

Link: https://lore.kernel.org/r/20210603000112.703037-2-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

scnprintf() returns the number of bytes written into the buffer.  Change
dsm_label_utf16s_to_utf8s() to do the same.  Rely on those values instead
of using strlen() to compute the buffer length.

No functional change intended.

[bhelgaas: reorder patch in series, len++ to include newline added by
dsm_label_utf16s_to_utf8s(), commit log]
Link: https://lore.kernel.org/r/20210603000112.703037-3-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

"utf16s_to_utf8s(..., buf, PAGE_SIZE)" puts up to PAGE_SIZE bytes into
"buf" and returns the number of bytes it actually put there.  If it wrote
PAGE_SIZE bytes, the newline added by dsm_label_utf16s_to_utf8s() would
overrun "buf".

Reduce the size available for utf16s_to_utf8s() to use so there is always
space for the newline.

[bhelgaas: reorder patch in series, commit log]
Fixes: 6058989 ("PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs")
Link: https://lore.kernel.org/r/20210603000112.703037-7-kw@linux.com
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

With the new method of flushing/stopping the workqueue before doing bus
removal, the old mechanism of using refcount and wait for completion
is no longer needed. Remove those dead code.

Link: https://lore.kernel.org/r/1620806809-31055-1-git-send-email-longli@linuxonhyperv.com
Signed-off-by: Long Li <longli@microsoft.com>
[lorenzo.pieralisi@arm.com: Reworded subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>

On removing the device, any work item (hv_pci_devices_present() or
hv_pci_eject_device()) scheduled on workqueue hbus->wq may still be running
and race with hv_pci_remove().

This can happen because the host may send PCI_EJECT or PCI_BUS_RELATIONS(2)
and decide to rescind the channel immediately after that.

Fix this by flushing/destroying the workqueue of hbus before doing hbus remove.

Link: https://lore.kernel.org/r/1620806800-30983-1-git-send-email-longli@linuxonhyperv.com
Signed-off-by: Long Li <longli@microsoft.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>

…erup()

When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.

Therefore, remove the error printing here to simplify code and reduce the
binary size.

Link: https://lore.kernel.org/r/20210511122453.6052-1-thunder.leizhen@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>

When devm_ioremap_resource() fails, a clear enough error message will be
printed by its subfunction __devm_ioremap_resource(). The error
information contains the device name, failure cause, and possibly resource
information.

Therefore, remove the error printing here to simplify code and reduce the
binary size.

Link: https://lore.kernel.org/r/20210511114547.5601-1-thunder.leizhen@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Acked-by: Richard Zhu <hongxing.zhu@nxp.com>

PCI_IOSIZE is defined in mach-loongson64/spaces.h, so change the name
of the PCI_* macros in pci-ftpci100.c to use FTPCI_* so that they are
more localized and won't conflict with other drivers or arches.

../drivers/pci/controller/pci-ftpci100.c:37: warning: "PCI_IOSIZE" redefined
   37 | #define PCI_IOSIZE 0x00
      |
In file included from ../arch/mips/include/asm/addrspace.h:13,
...              from ../drivers/pci/controller/pci-ftpci100.c:15:
arch/mips/include/asm/mach-loongson64/spaces.h:11: note: this is the location of the previous definition
   11 | #define PCI_IOSIZE SZ_16M

Suggested-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210517234117.3660-1-rdunlap@infradead.org
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: linux-mips@vger.kernel.org

The PCIe host controller driver for Layerscape 4th generation SoC was
added in the commit d29ad70 ("PCI: mobiveil: Add PCIe Gen4 RC
driver for Layerscape SoCs").

At this time two static functions were introduced that appear to
currently have no users.  Since nothing is using neither of these
functions at the moment they can be safely removed.

This resolves the following build time warnings:

  drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c:45:19: warning: unused function 'ls_pcie_g4_lut_readl' [-Wunused-function]
  drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c:50:20: warning: unused function 'ls_pcie_g4_lut_writel' [-Wunused-function]

Link: https://lore.kernel.org/r/20210510023032.3063932-1-kw@linux.com
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>