On Wed, 01 Sep 2021 12:29:22 +0100, Mark Kettenis <mark.kettenis@xxxxxxxxx> wrote: > > > Date: Tue, 31 Aug 2021 16:21:28 -0500 > > From: Rob Herring <robh@xxxxxxxxxx> > > > > On Fri, Aug 27, 2021 at 07:15:28PM +0200, Mark Kettenis wrote: > > > From: Mark Kettenis <kettenis@xxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxx> > > > --- > > > .../devicetree/bindings/pci/apple,pcie.yaml | 165 ++++++++++++++++++ > > > MAINTAINERS | 1 + > > > 2 files changed, 166 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..97a126db935a > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml > > > @@ -0,0 +1,165 @@ > > > +# 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@xxxxxxxxxxx> > > > + > > > +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. > > > + > > > + 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-gpios" and "max-link-speed" properties appear on > > > + the child nodes that represent the PCI bridges that correspond to > > > + the individual root ports. > > > + > > > + 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# > > > + - $ref: ../interrupt-controller/msi-controller.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-parent: true > > > > I still think this should be dropped as it is meaningless with > > 'msi-controller' present. > > Hmm. As far as I can tell all current arm64 device trees that > describe hardware with an MSI controller integrated on the PCI host > bridge have both the 'msi-controller' and 'msi-parent' properties. > See arch/arm64/boot/dts/marvell/aramada-37xx.dtsi and > arch/arm64/boot/dts/xilinx/zynqmp.dtsi. > > The current OpenBSD code will fail to map the MSIs if 'msi-parent' > isn't there, although Linux seems to fall back on an MSI domain that's > directly attached to the host bridge if the 'msi-parent' property is > missing. I think it makes sense to be explicit here, but if both you > and Marc think it shouldn't be there, I probably can change the > OpenBSD to do a similar fallback. I think this matches the behaviour we have for interrupt-controller vs interrupt-parent. I fail to see why msi-controller/msi-parent should behave differently. And since there is an established OS that actually requires this, I don't see how we can today make it illegal. M. -- Without deviation from the norm, progress is not possible.
