[PATCH v3 1/2] dt-bindings: pci: Add DT bindings for apple,pcie

[Rob Herring]

On Mon, Jul 26, 2021 at 10:32:00AM +0200, Mark Kettenis wrote:
> From: Mark Kettenis <kettenis at openbsd.org>
> 
> The Apple PCIe host controller is a PCIe host controller with
> multiple root ports present in Apple ARM SoC platforms, including
> various iPhone and iPad devices and the "Apple Silicon" Macs.
> 
> Signed-off-by: Mark Kettenis <kettenis at openbsd.org>
> ---
>  .../devicetree/bindings/pci/apple,pcie.yaml   | 166 ++++++++++++++++++
>  MAINTAINERS                                   |   1 +
>  2 files changed, 167 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/apple,pcie.yaml
> 
> diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> new file mode 100644
> index 000000000000..bfcbdee79c64
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml
> @@ -0,0 +1,166 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/apple,pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple PCIe host controller
> +
> +maintainers:
> +  - Mark Kettenis <kettenis at openbsd.org>
> +
> +description: |
> +  The Apple PCIe host controller is a PCIe host controller with
> +  multiple root ports present in Apple ARM SoC platforms, including
> +  various iPhone and iPad devices and the "Apple Silicon" Macs.
> +  The controller incorporates Synopsys DesigWare PCIe logic to
> +  implements its root ports.  But the ATU found on most DesignWare
> +  PCIe host bridges is absent.

blank line

> +  All root ports share a single ECAM space, but separate GPIOs are
> +  used to take the PCI devices on those ports out of reset.  Therefore
> +  the standard "reset-gpio" and "max-link-speed" properties appear on

reset-gpios

> +  the child nodes that represent the PCI bridges that correspond to
> +  the individual root ports.

blank line

> +  MSIs are handled by the PCIe controller and translated into regular
> +  interrupts.  A range of 32 MSIs is provided.  These 32 MSIs can be
> +  distributed over the root ports as the OS sees fit by programming
> +  the PCIe controller's port registers.
> +
> +allOf:
> +  - $ref: /schemas/pci/pci-bus.yaml#
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: apple,t8103-pcie
> +      - const: apple,pcie
> +
> +  reg:
> +    minItems: 3
> +    maxItems: 5
> +
> +  reg-names:
> +    minItems: 3
> +    maxItems: 5
> +    items:
> +      - const: config
> +      - const: rc
> +      - const: port0
> +      - const: port1
> +      - const: port2
> +
> +  ranges:
> +    minItems: 2
> +    maxItems: 2
> +
> +  interrupts:
> +    description:
> +      Interrupt specifiers, one for each root port.
> +    minItems: 1
> +    maxItems: 3
> +
> +  msi-controller: true
> +  msi-parent: true
> +
> +  msi-ranges:
> +    description:
> +      A list of pairs <intid span>, where "intid" is the first
> +      interrupt number that can be used as an MSI, and "span" the size
> +      of that range.
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    items:
> +      minItems: 2
> +      maxItems: 2

I still have issues I raised on v1 with this property. It's genericish 
looking, but not generic. 'intid' as a single cell can't specify any 
parent interrupt such as a GIC which uses 3 cells. You could put in all 
the cells, but you'd still be assuming which cell you can increment.

I think you should just list all these under 'interrupts' using 
interrupt-names to make your life easier:

interrupt-names:
  items:
    - const: port0
    - const: port1
    - const: port2
    - const: msi0
    - const: msi1
    - const: msi2
    - const: msi3
    ...

Yeah, it's kind of verbose, but if the h/w block handles N interrupts, 
you should list N interrupts. The worst case for the above is N entries 
too if not contiguous.

Rob