Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[kernel test robot]

:::::: 
:::::: Manual check reason: "dtcheck: binding changes may go via different trees"
:::::: 

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20260319160110.2131954-4-thierry.reding@kernel.org>
References: <20260319160110.2131954-4-thierry.reding@kernel.org>
TO: Thierry Reding <thierry.reding@kernel.org>
TO: Thierry Reding <thierry.reding@kernel.org>
TO: Bjorn Helgaas <helgaas@kernel.org>
TO: Lorenzo Pieralisi <lpieralisi@kernel.org>
TO: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
TO: Manivannan Sadhasivam <mani@kernel.org>
TO: Rob Herring <robh@kernel.org>
TO: Krzysztof Kozlowski <krzk@kernel.org>
TO: Conor Dooley <conor+dt@kernel.org>
CC: Jon Hunter <jonathanh@nvidia.com>
CC: linux-pci@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-tegra@vger.kernel.org

Hi Thierry,

kernel test robot noticed the following build warnings:

[auto build test WARNING on tegra/for-next]
[cannot apply to pci/next pci/for-linus robh/for-next linus/master v6.16-rc1 next-20260319]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Thierry-Reding/soc-tegra-Update-BPMP-ABI-header/20260320-025556
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
patch link:    https://lore.kernel.org/r/20260319160110.2131954-4-thierry.reding%40kernel.org
patch subject: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
:::::: branch date: 11 hours ago
:::::: commit date: 11 hours ago
config: openrisc-randconfig-2051-20260320 (https://download.01.org/0day-ci/archive/20260320/202603200723.Bh7b8npy-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 11.5.0
dtschema: 2025.13.dev8+g0515abdd9
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260320/202603200723.Bh7b8npy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202603200723.Bh7b8npy-lkp@intel.com/

dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml:61:5: [warning] wrong indentation: expected 6 but found 4 (indentation)
   Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml:52:2: [warning] wrong indentation: expected 2 but found 1 (indentation)
   Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.yaml:84:1: [warning] too many blank lines (2 > 1) (empty-lines)

vim +61 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml

12a9b5ad8d4182 Thierry Reding 2026-03-19  50  
12a9b5ad8d4182 Thierry Reding 2026-03-19  51  required:
12a9b5ad8d4182 Thierry Reding 2026-03-19  52    - interrupt-map
12a9b5ad8d4182 Thierry Reding 2026-03-19  53    - interrupt-map-mask
12a9b5ad8d4182 Thierry Reding 2026-03-19  54    - iommu-map
12a9b5ad8d4182 Thierry Reding 2026-03-19  55    - msi-map
12a9b5ad8d4182 Thierry Reding 2026-03-19  56    - nvidia,bpmp
12a9b5ad8d4182 Thierry Reding 2026-03-19  57  
12a9b5ad8d4182 Thierry Reding 2026-03-19  58  allOf:
12a9b5ad8d4182 Thierry Reding 2026-03-19  59    - $ref: /schemas/pci/pci-host-bridge.yaml#
12a9b5ad8d4182 Thierry Reding 2026-03-19  60    - oneOf:
12a9b5ad8d4182 Thierry Reding 2026-03-19 @61      - description: C0 controller (no UPHY)

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH 0/5] PCI: tegra: Add Tegra264 support

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Hi,

this series adds support for the PCIe controllers found on the Tegra264
SoC. There are six instances, one of which is for internal purposes only
and the other five are general purpose.

The first two patches in the series add the BPMP support needed to power
up/down the PCI link. Patch 3 contains the device tree bindings for the
PCIe controller and patch 4 adds the driver. Finally, patch 5 adds DT
nodes for the controllers found on the Tegra264 SoC.

Regarding merging these patches, I think ideally I'd want to pick up the
PCI driver patch into the Tegra tree because there is a build dependency
on patches 1 and 2. Furthermore, patch 1 depends on another patch that's
already in the Tegra tree, and there will be conflicts if it is merged
in another tree. Alternatively I can provide a stable branch with
patches 1 and 2 for the PCI maintainers to pull in.

Let me know how you'd like to handle this.

Thanks,
Thierry

Thierry Reding (5):
  soc/tegra: Update BPMP ABI header
  firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function
  dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller
  PCI: tegra: Add Tegra264 support
  arm64: tegra: Add PCI controllers on Tegra264

 .../bindings/pci/nvidia,tegra264-pcie.yaml    |   92 +
 arch/arm64/boot/dts/nvidia/tegra264.dtsi      |  248 +-
 drivers/firmware/tegra/bpmp.c                 |   34 +
 drivers/pci/controller/Kconfig                |    8 +
 drivers/pci/controller/Makefile               |    1 +
 drivers/pci/controller/pcie-tegra264.c        |  506 ++
 include/soc/tegra/bpmp-abi.h                  | 4565 +++++++++++++----
 include/soc/tegra/bpmp.h                      |    1 +
 8 files changed, 4534 insertions(+), 921 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
 create mode 100644 drivers/pci/controller/pcie-tegra264.c

-- 
2.52.0

[PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

The six PCIe controllers found on Tegra264 are of two types: one is used
for the internal GPU and therefore is not connected to a UPHY and the
remaining five controllers are typically routed to a PCI slot and have
additional controls for the physical link.

While these controllers can be switched into endpoint mode, this binding
describes the root complex mode only.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml

diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
new file mode 100644
index 000000000000..56d69de2788b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra264 PCIe controller
+
+maintainers:
+  - Thierry Reding <thierry.reding@gmail.com>
+  - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+  compatible:
+    const: nvidia,tegra264-pcie
+
+  reg:
+    minItems: 4
+    maxItems: 5
+
+  reg-names:
+    minItems: 4
+    maxItems: 5
+
+  interrupts:
+    minItems: 1
+    maxItems: 4
+
+  dma-coherent: true
+
+  nvidia,bpmp:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description: |
+      Must contain a pair of phandle (to the BPMP controller node) and
+      controller ID. The following are the controller IDs for each controller:
+
+      0: C0
+      1: C1
+      2: C2
+      3: C3
+      4: C4
+      5: C5
+    items:
+      - items:
+          - description: phandle to the BPMP controller node
+          - description: PCIe controller ID
+            maximum: 5
+
+unevaluatedProperties: false
+
+required:
+  - interrupt-map
+  - interrupt-map-mask
+  - iommu-map
+  - msi-map
+  - nvidia,bpmp
+
+allOf:
+  - $ref: /schemas/pci/pci-host-bridge.yaml#
+  - oneOf:
+    - description: C0 controller (no UPHY)
+      properties:
+        reg:
+          items:
+            - description: application layer registers
+            - description: transaction layer registers
+            - description: privileged transaction layer registers
+            - description: ECAM-compatible configuration space
+
+        reg-names:
+          items:
+            - const: xal
+            - const: xtl
+            - const: xtl-pri
+            - const: ecam
+
+    - description: C1-C5 controllers (with UPHY)
+      properties:
+        reg:
+          items:
+            - description: application layer registers
+            - description: transaction layer registers
+            - description: privileged transaction layer registers
+            - description: data link/physical layer registers
+            - description: ECAM-compatible configuration space
+
+      items:
+        - const: xal
+        - const: xtl
+        - const: xtl-pri
+        - const: xpl
+        - const: ecam
-- 
2.52.0

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Krzysztof Kozlowski]

On 19/03/2026 17:01, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> The six PCIe controllers found on Tegra264 are of two types: one is used
> for the internal GPU and therefore is not connected to a UPHY and the
> remaining five controllers are typically routed to a PCI slot and have
> additional controls for the physical link.
> 
> While these controllers can be switched into endpoint mode, this binding
> describes the root complex mode only.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> 
> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> new file mode 100644
> index 000000000000..56d69de2788b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra264 PCIe controller
> +
> +maintainers:
> +  - Thierry Reding <thierry.reding@gmail.com>
> +  - Jon Hunter <jonathanh@nvidia.com>
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra264-pcie
> +
> +  reg:
> +    minItems: 4
> +    maxItems: 5
> +
> +  reg-names:
> +    minItems: 4
> +    maxItems: 5
> +
> +  interrupts:
> +    minItems: 1
> +    maxItems: 4
> +
> +  dma-coherent: true
> +
> +  nvidia,bpmp:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      Must contain a pair of phandle (to the BPMP controller node) and
> +      controller ID. The following are the controller IDs for each controller:
> +
> +      0: C0
> +      1: C1
> +      2: C2
> +      3: C3
> +      4: C4
> +      5: C5
> +    items:
> +      - items:
> +          - description: phandle to the BPMP controller node
> +          - description: PCIe controller ID
> +            maximum: 5
> +
> +unevaluatedProperties: false

This goes before example

> +
> +required:
> +  - interrupt-map
> +  - interrupt-map-mask
> +  - iommu-map
> +  - msi-map
> +  - nvidia,bpmp
> +
> +allOf:
> +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> +  - oneOf:
> +    - description: C0 controller (no UPHY)

It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint. Don't rely on
distro packages for dtschema and be sure you are using the latest
released dtschema.

> +      properties:
> +        reg:
> +          items:
> +            - description: application layer registers
> +            - description: transaction layer registers
> +            - description: privileged transaction layer registers
> +            - description: ECAM-compatible configuration space
> +
> +        reg-names:
> +          items:
> +            - const: xal
> +            - const: xtl
> +            - const: xtl-pri
> +            - const: ecam
> +
> +    - description: C1-C5 controllers (with UPHY)
> +      properties:
> +        reg:
> +          items:
> +            - description: application layer registers
> +            - description: transaction layer registers
> +            - description: privileged transaction layer registers
> +            - description: data link/physical layer registers
> +            - description: ECAM-compatible configuration space
> +
> +      items:
> +        - const: xal
> +        - const: xtl
> +        - const: xtl-pri
> +        - const: xpl
> +        - const: ecam

All of above are part of top level.

And speaking about example - where is it? How can you then test (verify)
this?

Best regards,
Krzysztof

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4969 bytes --]

On Thu, Mar 19, 2026 at 05:11:17PM +0100, Krzysztof Kozlowski wrote:
> On 19/03/2026 17:01, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > The six PCIe controllers found on Tegra264 are of two types: one is used
> > for the internal GPU and therefore is not connected to a UPHY and the
> > remaining five controllers are typically routed to a PCI slot and have
> > additional controls for the physical link.
> > 
> > While these controllers can be switched into endpoint mode, this binding
> > describes the root complex mode only.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> >  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > new file mode 100644
> > index 000000000000..56d69de2788b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVIDIA Tegra264 PCIe controller
> > +
> > +maintainers:
> > +  - Thierry Reding <thierry.reding@gmail.com>
> > +  - Jon Hunter <jonathanh@nvidia.com>
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra264-pcie
> > +
> > +  reg:
> > +    minItems: 4
> > +    maxItems: 5
> > +
> > +  reg-names:
> > +    minItems: 4
> > +    maxItems: 5
> > +
> > +  interrupts:
> > +    minItems: 1
> > +    maxItems: 4
> > +
> > +  dma-coherent: true
> > +
> > +  nvidia,bpmp:
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +    description: |
> > +      Must contain a pair of phandle (to the BPMP controller node) and
> > +      controller ID. The following are the controller IDs for each controller:
> > +
> > +      0: C0
> > +      1: C1
> > +      2: C2
> > +      3: C3
> > +      4: C4
> > +      5: C5
> > +    items:
> > +      - items:
> > +          - description: phandle to the BPMP controller node
> > +          - description: PCIe controller ID
> > +            maximum: 5
> > +
> > +unevaluatedProperties: false
> 
> This goes before example
> 
> > +
> > +required:
> > +  - interrupt-map
> > +  - interrupt-map-mask
> > +  - iommu-map
> > +  - msi-map
> > +  - nvidia,bpmp
> > +
> > +allOf:
> > +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> > +  - oneOf:
> > +    - description: C0 controller (no UPHY)
> 
> It does not look like you tested the bindings, at least after quick
> look. Please run `make dt_binding_check` (see
> Documentation/devicetree/bindings/writing-schema.rst for instructions).
> Maybe you need to update your dtschema and yamllint. Don't rely on
> distro packages for dtschema and be sure you are using the latest
> released dtschema.

I certainly validated the DTBs resulting from this series and didn't see
any issues. I thought that previously also ran the linter and bindings
checks, but it looks like it doesn't, so I'll need to update my script
to do so explicitly.

dtschema should be up-to-date as well.

> 
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: application layer registers
> > +            - description: transaction layer registers
> > +            - description: privileged transaction layer registers
> > +            - description: ECAM-compatible configuration space
> > +
> > +        reg-names:
> > +          items:
> > +            - const: xal
> > +            - const: xtl
> > +            - const: xtl-pri
> > +            - const: ecam
> > +
> > +    - description: C1-C5 controllers (with UPHY)
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: application layer registers
> > +            - description: transaction layer registers
> > +            - description: privileged transaction layer registers
> > +            - description: data link/physical layer registers
> > +            - description: ECAM-compatible configuration space
> > +
> > +      items:
> > +        - const: xal
> > +        - const: xtl
> > +        - const: xtl-pri
> > +        - const: xpl
> > +        - const: ecam
> 
> All of above are part of top level.
> 
> And speaking about example - where is it? How can you then test (verify)
> this?

I'm using the DTB resulting from the last patch in this series to
validate an actual example. I suppose I can extract an example into the
bindings, but I thought this was no longer a strict requirement.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Rob Herring (Arm)]

On Thu, 19 Mar 2026 17:01:07 +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> The six PCIe controllers found on Tegra264 are of two types: one is used
> for the internal GPU and therefore is not connected to a UPHY and the
> remaining five controllers are typically routed to a PCI slot and have
> additional controls for the physical link.
> 
> While these controllers can be switched into endpoint mode, this binding
> describes the root complex mode only.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml:61:5: [warning] wrong indentation: expected 6 but found 4 (indentation)

dtschema/dtc warnings/errors:

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260319160110.2131954-4-thierry.reding@kernel.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Rob Herring]

On Thu, Mar 19, 2026 at 11:01 AM Thierry Reding
<thierry.reding@kernel.org> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> The six PCIe controllers found on Tegra264 are of two types: one is used
> for the internal GPU and therefore is not connected to a UPHY and the
> remaining five controllers are typically routed to a PCI slot and have
> additional controls for the physical link.
>
> While these controllers can be switched into endpoint mode, this binding
> describes the root complex mode only.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> new file mode 100644
> index 000000000000..56d69de2788b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra264 PCIe controller
> +
> +maintainers:
> +  - Thierry Reding <thierry.reding@gmail.com>
> +  - Jon Hunter <jonathanh@nvidia.com>
> +
> +properties:
> +  compatible:
> +    const: nvidia,tegra264-pcie
> +
> +  reg:
> +    minItems: 4
> +    maxItems: 5
> +
> +  reg-names:
> +    minItems: 4
> +    maxItems: 5
> +
> +  interrupts:
> +    minItems: 1
> +    maxItems: 4
> +
> +  dma-coherent: true
> +
> +  nvidia,bpmp:
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    description: |
> +      Must contain a pair of phandle (to the BPMP controller node) and
> +      controller ID. The following are the controller IDs for each controller:
> +
> +      0: C0
> +      1: C1
> +      2: C2
> +      3: C3
> +      4: C4
> +      5: C5
> +    items:
> +      - items:
> +          - description: phandle to the BPMP controller node
> +          - description: PCIe controller ID
> +            maximum: 5
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - interrupt-map
> +  - interrupt-map-mask
> +  - iommu-map
> +  - msi-map
> +  - nvidia,bpmp
> +
> +allOf:
> +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> +  - oneOf:
> +    - description: C0 controller (no UPHY)
> +      properties:
> +        reg:
> +          items:
> +            - description: application layer registers
> +            - description: transaction layer registers
> +            - description: privileged transaction layer registers
> +            - description: ECAM-compatible configuration space
> +
> +        reg-names:
> +          items:
> +            - const: xal
> +            - const: xtl
> +            - const: xtl-pri
> +            - const: ecam
> +
> +    - description: C1-C5 controllers (with UPHY)
> +      properties:
> +        reg:
> +          items:
> +            - description: application layer registers
> +            - description: transaction layer registers
> +            - description: privileged transaction layer registers
> +            - description: data link/physical layer registers
> +            - description: ECAM-compatible configuration space
> +
> +      items:
> +        - const: xal
> +        - const: xtl
> +        - const: xtl-pri
> +        - const: xpl

Put this entry last since it is the optional one. Then you can move
all of this to the top-level and get rid of the duplication.

> +        - const: ecam
> --
> 2.52.0
>

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4742 bytes --]

On Thu, Mar 19, 2026 at 04:26:31PM -0500, Rob Herring wrote:
> On Thu, Mar 19, 2026 at 11:01 AM Thierry Reding
> <thierry.reding@kernel.org> wrote:
> >
> > From: Thierry Reding <treding@nvidia.com>
> >
> > The six PCIe controllers found on Tegra264 are of two types: one is used
> > for the internal GPU and therefore is not connected to a UPHY and the
> > remaining five controllers are typically routed to a PCI slot and have
> > additional controls for the physical link.
> >
> > While these controllers can be switched into endpoint mode, this binding
> > describes the root complex mode only.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> >  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
> >  1 file changed, 92 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > new file mode 100644
> > index 000000000000..56d69de2788b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > @@ -0,0 +1,92 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVIDIA Tegra264 PCIe controller
> > +
> > +maintainers:
> > +  - Thierry Reding <thierry.reding@gmail.com>
> > +  - Jon Hunter <jonathanh@nvidia.com>
> > +
> > +properties:
> > +  compatible:
> > +    const: nvidia,tegra264-pcie
> > +
> > +  reg:
> > +    minItems: 4
> > +    maxItems: 5
> > +
> > +  reg-names:
> > +    minItems: 4
> > +    maxItems: 5
> > +
> > +  interrupts:
> > +    minItems: 1
> > +    maxItems: 4
> > +
> > +  dma-coherent: true
> > +
> > +  nvidia,bpmp:
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +    description: |
> > +      Must contain a pair of phandle (to the BPMP controller node) and
> > +      controller ID. The following are the controller IDs for each controller:
> > +
> > +      0: C0
> > +      1: C1
> > +      2: C2
> > +      3: C3
> > +      4: C4
> > +      5: C5
> > +    items:
> > +      - items:
> > +          - description: phandle to the BPMP controller node
> > +          - description: PCIe controller ID
> > +            maximum: 5
> > +
> > +unevaluatedProperties: false
> > +
> > +required:
> > +  - interrupt-map
> > +  - interrupt-map-mask
> > +  - iommu-map
> > +  - msi-map
> > +  - nvidia,bpmp
> > +
> > +allOf:
> > +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> > +  - oneOf:
> > +    - description: C0 controller (no UPHY)
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: application layer registers
> > +            - description: transaction layer registers
> > +            - description: privileged transaction layer registers
> > +            - description: ECAM-compatible configuration space
> > +
> > +        reg-names:
> > +          items:
> > +            - const: xal
> > +            - const: xtl
> > +            - const: xtl-pri
> > +            - const: ecam
> > +
> > +    - description: C1-C5 controllers (with UPHY)
> > +      properties:
> > +        reg:
> > +          items:
> > +            - description: application layer registers
> > +            - description: transaction layer registers
> > +            - description: privileged transaction layer registers
> > +            - description: data link/physical layer registers
> > +            - description: ECAM-compatible configuration space
> > +
> > +      items:
> > +        - const: xal
> > +        - const: xtl
> > +        - const: xtl-pri
> > +        - const: xpl
> 
> Put this entry last since it is the optional one. Then you can move
> all of this to the top-level and get rid of the duplication.

I understand this concern and was actually on the fence about this
myself. The reason why I ultimately went with this variant is for two
reasons:

  1. XPL does not exist for controller 0, the variant above makes that
     very explicit. It explicitly documents that controller 0 is used
     for internal purposes and cannot be connected to an external port
     like the other five controllers.

  2. The ECAM region is part of a memory region specifically reserved
     for configuration space, whereas all of the other regions are
     from the controller's MMIO region. I find the DT hard to read if
     the two are interleaved.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Rob Herring]

On Fri, Mar 20, 2026 at 4:39 AM Thierry Reding
<thierry.reding@kernel.org> wrote:
>
> On Thu, Mar 19, 2026 at 04:26:31PM -0500, Rob Herring wrote:
> > On Thu, Mar 19, 2026 at 11:01 AM Thierry Reding
> > <thierry.reding@kernel.org> wrote:
> > >
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > The six PCIe controllers found on Tegra264 are of two types: one is used
> > > for the internal GPU and therefore is not connected to a UPHY and the
> > > remaining five controllers are typically routed to a PCI slot and have
> > > additional controls for the physical link.
> > >
> > > While these controllers can be switched into endpoint mode, this binding
> > > describes the root complex mode only.
> > >
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > ---
> > >  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
> > >  1 file changed, 92 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > new file mode 100644
> > > index 000000000000..56d69de2788b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > @@ -0,0 +1,92 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: NVIDIA Tegra264 PCIe controller
> > > +
> > > +maintainers:
> > > +  - Thierry Reding <thierry.reding@gmail.com>
> > > +  - Jon Hunter <jonathanh@nvidia.com>
> > > +
> > > +properties:
> > > +  compatible:
> > > +    const: nvidia,tegra264-pcie
> > > +
> > > +  reg:
> > > +    minItems: 4
> > > +    maxItems: 5
> > > +
> > > +  reg-names:
> > > +    minItems: 4
> > > +    maxItems: 5
> > > +
> > > +  interrupts:
> > > +    minItems: 1
> > > +    maxItems: 4
> > > +
> > > +  dma-coherent: true
> > > +
> > > +  nvidia,bpmp:
> > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +    description: |
> > > +      Must contain a pair of phandle (to the BPMP controller node) and
> > > +      controller ID. The following are the controller IDs for each controller:
> > > +
> > > +      0: C0
> > > +      1: C1
> > > +      2: C2
> > > +      3: C3
> > > +      4: C4
> > > +      5: C5
> > > +    items:
> > > +      - items:
> > > +          - description: phandle to the BPMP controller node
> > > +          - description: PCIe controller ID
> > > +            maximum: 5
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +required:
> > > +  - interrupt-map
> > > +  - interrupt-map-mask
> > > +  - iommu-map
> > > +  - msi-map
> > > +  - nvidia,bpmp
> > > +
> > > +allOf:
> > > +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> > > +  - oneOf:
> > > +    - description: C0 controller (no UPHY)
> > > +      properties:
> > > +        reg:
> > > +          items:
> > > +            - description: application layer registers
> > > +            - description: transaction layer registers
> > > +            - description: privileged transaction layer registers
> > > +            - description: ECAM-compatible configuration space
> > > +
> > > +        reg-names:
> > > +          items:
> > > +            - const: xal
> > > +            - const: xtl
> > > +            - const: xtl-pri
> > > +            - const: ecam
> > > +
> > > +    - description: C1-C5 controllers (with UPHY)
> > > +      properties:
> > > +        reg:
> > > +          items:
> > > +            - description: application layer registers
> > > +            - description: transaction layer registers
> > > +            - description: privileged transaction layer registers
> > > +            - description: data link/physical layer registers
> > > +            - description: ECAM-compatible configuration space
> > > +
> > > +      items:
> > > +        - const: xal
> > > +        - const: xtl
> > > +        - const: xtl-pri
> > > +        - const: xpl
> >
> > Put this entry last since it is the optional one. Then you can move
> > all of this to the top-level and get rid of the duplication.
>
> I understand this concern and was actually on the fence about this
> myself. The reason why I ultimately went with this variant is for two
> reasons:
>
>   1. XPL does not exist for controller 0, the variant above makes that
>      very explicit. It explicitly documents that controller 0 is used
>      for internal purposes and cannot be connected to an external port
>      like the other five controllers.

That doesn't really matter to the schema because it can never check
that unless you have 2 different compatibles (and you shouldn't).

>   2. The ECAM region is part of a memory region specifically reserved
>      for configuration space, whereas all of the other regions are
>      from the controller's MMIO region. I find the DT hard to read if
>      the two are interleaved.

I was also going to suggest putting ECAM first just to align with the
generic host binding. That would make it slightly easier to rewrite
the node if you decided to make it a firmware initialized controller.

But if you really want it all as-is, fine.

Rob

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6001 bytes --]

On Fri, Mar 20, 2026 at 08:06:26AM -0500, Rob Herring wrote:
> On Fri, Mar 20, 2026 at 4:39 AM Thierry Reding
> <thierry.reding@kernel.org> wrote:
> >
> > On Thu, Mar 19, 2026 at 04:26:31PM -0500, Rob Herring wrote:
> > > On Thu, Mar 19, 2026 at 11:01 AM Thierry Reding
> > > <thierry.reding@kernel.org> wrote:
> > > >
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > The six PCIe controllers found on Tegra264 are of two types: one is used
> > > > for the internal GPU and therefore is not connected to a UPHY and the
> > > > remaining five controllers are typically routed to a PCI slot and have
> > > > additional controls for the physical link.
> > > >
> > > > While these controllers can be switched into endpoint mode, this binding
> > > > describes the root complex mode only.
> > > >
> > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > ---
> > > >  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
> > > >  1 file changed, 92 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > new file mode 100644
> > > > index 000000000000..56d69de2788b
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > @@ -0,0 +1,92 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: NVIDIA Tegra264 PCIe controller
> > > > +
> > > > +maintainers:
> > > > +  - Thierry Reding <thierry.reding@gmail.com>
> > > > +  - Jon Hunter <jonathanh@nvidia.com>
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: nvidia,tegra264-pcie
> > > > +
> > > > +  reg:
> > > > +    minItems: 4
> > > > +    maxItems: 5
> > > > +
> > > > +  reg-names:
> > > > +    minItems: 4
> > > > +    maxItems: 5
> > > > +
> > > > +  interrupts:
> > > > +    minItems: 1
> > > > +    maxItems: 4
> > > > +
> > > > +  dma-coherent: true
> > > > +
> > > > +  nvidia,bpmp:
> > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +    description: |
> > > > +      Must contain a pair of phandle (to the BPMP controller node) and
> > > > +      controller ID. The following are the controller IDs for each controller:
> > > > +
> > > > +      0: C0
> > > > +      1: C1
> > > > +      2: C2
> > > > +      3: C3
> > > > +      4: C4
> > > > +      5: C5
> > > > +    items:
> > > > +      - items:
> > > > +          - description: phandle to the BPMP controller node
> > > > +          - description: PCIe controller ID
> > > > +            maximum: 5
> > > > +
> > > > +unevaluatedProperties: false
> > > > +
> > > > +required:
> > > > +  - interrupt-map
> > > > +  - interrupt-map-mask
> > > > +  - iommu-map
> > > > +  - msi-map
> > > > +  - nvidia,bpmp
> > > > +
> > > > +allOf:
> > > > +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> > > > +  - oneOf:
> > > > +    - description: C0 controller (no UPHY)
> > > > +      properties:
> > > > +        reg:
> > > > +          items:
> > > > +            - description: application layer registers
> > > > +            - description: transaction layer registers
> > > > +            - description: privileged transaction layer registers
> > > > +            - description: ECAM-compatible configuration space
> > > > +
> > > > +        reg-names:
> > > > +          items:
> > > > +            - const: xal
> > > > +            - const: xtl
> > > > +            - const: xtl-pri
> > > > +            - const: ecam
> > > > +
> > > > +    - description: C1-C5 controllers (with UPHY)
> > > > +      properties:
> > > > +        reg:
> > > > +          items:
> > > > +            - description: application layer registers
> > > > +            - description: transaction layer registers
> > > > +            - description: privileged transaction layer registers
> > > > +            - description: data link/physical layer registers
> > > > +            - description: ECAM-compatible configuration space
> > > > +
> > > > +      items:
> > > > +        - const: xal
> > > > +        - const: xtl
> > > > +        - const: xtl-pri
> > > > +        - const: xpl
> > >
> > > Put this entry last since it is the optional one. Then you can move
> > > all of this to the top-level and get rid of the duplication.
> >
> > I understand this concern and was actually on the fence about this
> > myself. The reason why I ultimately went with this variant is for two
> > reasons:
> >
> >   1. XPL does not exist for controller 0, the variant above makes that
> >      very explicit. It explicitly documents that controller 0 is used
> >      for internal purposes and cannot be connected to an external port
> >      like the other five controllers.
> 
> That doesn't really matter to the schema because it can never check
> that unless you have 2 different compatibles (and you shouldn't).

I know that, the documentation would be more for developers/users rather
than the validation tools.

> >   2. The ECAM region is part of a memory region specifically reserved
> >      for configuration space, whereas all of the other regions are
> >      from the controller's MMIO region. I find the DT hard to read if
> >      the two are interleaved.
> 
> I was also going to suggest putting ECAM first just to align with the
> generic host binding. That would make it slightly easier to rewrite
> the node if you decided to make it a firmware initialized controller.

Huh... I hadn't considered that. I think that would be a compromise that
I can very well live with.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller

[Rob Herring]

On Fri, Mar 20, 2026 at 8:48 AM Thierry Reding
<thierry.reding@kernel.org> wrote:
>
> On Fri, Mar 20, 2026 at 08:06:26AM -0500, Rob Herring wrote:
> > On Fri, Mar 20, 2026 at 4:39 AM Thierry Reding
> > <thierry.reding@kernel.org> wrote:
> > >
> > > On Thu, Mar 19, 2026 at 04:26:31PM -0500, Rob Herring wrote:
> > > > On Thu, Mar 19, 2026 at 11:01 AM Thierry Reding
> > > > <thierry.reding@kernel.org> wrote:
> > > > >
> > > > > From: Thierry Reding <treding@nvidia.com>
> > > > >
> > > > > The six PCIe controllers found on Tegra264 are of two types: one is used
> > > > > for the internal GPU and therefore is not connected to a UPHY and the
> > > > > remaining five controllers are typically routed to a PCI slot and have
> > > > > additional controls for the physical link.
> > > > >
> > > > > While these controllers can be switched into endpoint mode, this binding
> > > > > describes the root complex mode only.
> > > > >
> > > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > > ---
> > > > >  .../bindings/pci/nvidia,tegra264-pcie.yaml    | 92 +++++++++++++++++++
> > > > >  1 file changed, 92 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..56d69de2788b
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
> > > > > @@ -0,0 +1,92 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/pci/nvidia,tegra264-pcie.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: NVIDIA Tegra264 PCIe controller
> > > > > +
> > > > > +maintainers:
> > > > > +  - Thierry Reding <thierry.reding@gmail.com>
> > > > > +  - Jon Hunter <jonathanh@nvidia.com>
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: nvidia,tegra264-pcie
> > > > > +
> > > > > +  reg:
> > > > > +    minItems: 4
> > > > > +    maxItems: 5
> > > > > +
> > > > > +  reg-names:
> > > > > +    minItems: 4
> > > > > +    maxItems: 5
> > > > > +
> > > > > +  interrupts:
> > > > > +    minItems: 1
> > > > > +    maxItems: 4
> > > > > +
> > > > > +  dma-coherent: true
> > > > > +
> > > > > +  nvidia,bpmp:
> > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +    description: |
> > > > > +      Must contain a pair of phandle (to the BPMP controller node) and
> > > > > +      controller ID. The following are the controller IDs for each controller:
> > > > > +
> > > > > +      0: C0
> > > > > +      1: C1
> > > > > +      2: C2
> > > > > +      3: C3
> > > > > +      4: C4
> > > > > +      5: C5
> > > > > +    items:
> > > > > +      - items:
> > > > > +          - description: phandle to the BPMP controller node
> > > > > +          - description: PCIe controller ID
> > > > > +            maximum: 5
> > > > > +
> > > > > +unevaluatedProperties: false
> > > > > +
> > > > > +required:
> > > > > +  - interrupt-map
> > > > > +  - interrupt-map-mask
> > > > > +  - iommu-map
> > > > > +  - msi-map
> > > > > +  - nvidia,bpmp
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: /schemas/pci/pci-host-bridge.yaml#
> > > > > +  - oneOf:
> > > > > +    - description: C0 controller (no UPHY)
> > > > > +      properties:
> > > > > +        reg:
> > > > > +          items:
> > > > > +            - description: application layer registers
> > > > > +            - description: transaction layer registers
> > > > > +            - description: privileged transaction layer registers
> > > > > +            - description: ECAM-compatible configuration space
> > > > > +
> > > > > +        reg-names:
> > > > > +          items:
> > > > > +            - const: xal
> > > > > +            - const: xtl
> > > > > +            - const: xtl-pri
> > > > > +            - const: ecam
> > > > > +
> > > > > +    - description: C1-C5 controllers (with UPHY)
> > > > > +      properties:
> > > > > +        reg:
> > > > > +          items:
> > > > > +            - description: application layer registers
> > > > > +            - description: transaction layer registers
> > > > > +            - description: privileged transaction layer registers
> > > > > +            - description: data link/physical layer registers
> > > > > +            - description: ECAM-compatible configuration space
> > > > > +
> > > > > +      items:
> > > > > +        - const: xal
> > > > > +        - const: xtl
> > > > > +        - const: xtl-pri
> > > > > +        - const: xpl
> > > >
> > > > Put this entry last since it is the optional one. Then you can move
> > > > all of this to the top-level and get rid of the duplication.
> > >
> > > I understand this concern and was actually on the fence about this
> > > myself. The reason why I ultimately went with this variant is for two
> > > reasons:
> > >
> > >   1. XPL does not exist for controller 0, the variant above makes that
> > >      very explicit. It explicitly documents that controller 0 is used
> > >      for internal purposes and cannot be connected to an external port
> > >      like the other five controllers.
> >
> > That doesn't really matter to the schema because it can never check
> > that unless you have 2 different compatibles (and you shouldn't).
>
> I know that, the documentation would be more for developers/users rather
> than the validation tools.

You can add whatever documentation you want to express that without
needlessly complicating the schema for no validation purpose. Arguably
if the schema is shorter, that documentation will be easier to see.

Rob