lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 31 Jul 2021 11:44:59 +0200 (CEST)
From:   Mark Kettenis <mark.kettenis@...all.nl>
To:     Rob Herring <robh@...nel.org>, maz@...nel.org
Cc:     devicetree@...r.kernel.org, robin.murphy@....com,
        sven@...npeter.dev, kettenis@...nbsd.org, marcan@...can.st,
        bhelgaas@...gle.com, linux-arm-kernel@...ts.infradead.org,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: pci: Add DT bindings for apple,pcie

> Date: Mon, 26 Jul 2021 17:18:48 -0600
> From: Rob Herring <robh@...nel.org>

Hi Rob,

> On Mon, Jul 26, 2021 at 10:32:00AM +0200, Mark Kettenis wrote:
> > From: Mark Kettenis <kettenis@...nbsd.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@...nbsd.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@...nbsd.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

Fixing these for v4.

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

Not sure what you mean with "specify any parent interrupt" here.  For
the GIC and AIC the three cells encode the interrupt type, interrupt
number, and trigger level/polarity.  And for MSIs the interrupt type
and trigger level/polarity are pretty much implied.  It is genericish
in the sense that it follows the pattern of the "mbi-ranges" in the
arm,gic-v3.yaml binding.

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

Hmm, "msi-ranges" was what Marc Zyngier came up with since he didn't
really like the approach you sketch above.  And he gave this version
of the binding his blessing.  Your approach would work fine as well,
although doing a string-based lookup for each MSI vector is a bit
ugly.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ