| 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
| ||
|
Message-ID: <CAKfTPtD2MH9_xT+Fq4vvpGNMJPSkwh3CMaVCLRcNxrn_Ab7eLQ@mail.gmail.com>
Date: Tue, 23 Sep 2025 19:40:40 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: chester62515@...il.com, mbrugger@...e.com, ghennadi.procopciuc@....nxp.com,
s32@....com, bhelgaas@...gle.com, jingoohan1@...il.com, lpieralisi@...nel.org,
kwilczynski@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, Ionut.Vicovan@....com, larisa.grigore@....com,
Ghennadi.Procopciuc@....com, ciprianmarian.costea@....com,
bogdan.hamciuc@....com, Frank.li@....com,
linux-arm-kernel@...ts.infradead.org, linux-pci@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
cassel@...nel.org
Subject: Re: [PATCH 1/3 v2] dt-bindings: PCI: s32g: Add NXP PCIe controller
On Mon, 22 Sept 2025 at 08:21, Manivannan Sadhasivam <mani@...nel.org> wrote:
>
> On Fri, Sep 19, 2025 at 05:58:19PM +0200, Vincent Guittot wrote:
> > Describe the PCIe controller available on the S32G platforms.
> >
>
> You should mention that this binding is for the controller operating in 'Root
> Complex' mode.
>
> > Co-developed-by: Ionut Vicovan <Ionut.Vicovan@....com>
> > Signed-off-by: Ionut Vicovan <Ionut.Vicovan@....com>
> > Co-developed-by: Bogdan-Gabriel Roman <bogdan-gabriel.roman@....com>
> > Signed-off-by: Bogdan-Gabriel Roman <bogdan-gabriel.roman@....com>
> > Co-developed-by: Larisa Grigore <larisa.grigore@....com>
> > Signed-off-by: Larisa Grigore <larisa.grigore@....com>
> > Co-developed-by: Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>
> > Signed-off-by: Ghennadi Procopciuc <Ghennadi.Procopciuc@....com>
> > Co-developed-by: Ciprian Marian Costea <ciprianmarian.costea@....com>
> > Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@....com>
> > Co-developed-by: Bogdan Hamciuc <bogdan.hamciuc@....com>
> > Signed-off-by: Bogdan Hamciuc <bogdan.hamciuc@....com>
> > Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> > ---
> > .../devicetree/bindings/pci/nxp,s32-pcie.yaml | 131 ++++++++++++++++++
> > 1 file changed, 131 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/nxp,s32-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/nxp,s32-pcie.yaml b/Documentation/devicetree/bindings/pci/nxp,s32-pcie.yaml
> > new file mode 100644
> > index 000000000000..cabb8b86c042
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/nxp,s32-pcie.yaml
> > @@ -0,0 +1,131 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/nxp,s32-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NXP S32G2xx/S32G3xx PCIe controller
> > +
> > +maintainers:
> > + - Bogdan Hamciuc <bogdan.hamciuc@....com>
> > + - Ionut Vicovan <ionut.vicovan@....com>
> > +
> > +description:
> > + This PCIe controller is based on the Synopsys DesignWare PCIe IP.
> > + The S32G SoC family has two PCIe controllers, which can be configured as
> > + either Root Complex or Endpoint.
> > +
>
> But this binding is going to cover only the 'Root Complex' mode, isn't it?
I was planning to add the endpoint in the same file as the hardware
description remains the same between RC and EP but only the use of the
HW is different. But it looks like I have to separate binding for RC
and endpoint
>
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - nxp,s32g2-pcie # S32G2 SoCs RC mode
> > + - items:
> > + - const: nxp,s32g3-pcie
> > + - const: nxp,s32g2-pcie
> > +
> > + reg:
> > + maxItems: 7
> > +
> > + reg-names:
> > + items:
> > + - const: dbi
> > + - const: dbi2
> > + - const: atu
> > + - const: dma
> > + - const: ctrl
> > + - const: config
> > + - const: addr_space
> > +
> > + interrupts:
> > + maxItems: 8
> > +
> > + interrupt-names:
> > + items:
> > + - const: link-req-stat
> > + - const: dma
> > + - const: msi
> > + - const: phy-link-down
> > + - const: phy-link-up
> > + - const: misc
> > + - const: pcs
> > + - const: tlp-req-no-comp
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - interrupts
> > + - interrupt-names
> > + - ranges
> > + - phys
> > +
> > +allOf:
> > + - $ref: /schemas/pci/snps,dw-pcie-common.yaml#
> > + - $ref: /schemas/pci/pci-bus.yaml#
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/phy/phy.h>
> > +
> > + bus {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + pcie@...00000 {
> > + compatible = "nxp,s32g3-pcie",
> > + "nxp,s32g2-pcie";
> > + reg = <0x00 0x40400000 0x0 0x00001000>, /* dbi registers */
> > + <0x00 0x40420000 0x0 0x00001000>, /* dbi2 registers */
> > + <0x00 0x40460000 0x0 0x00001000>, /* atu registers */
> > + <0x00 0x40470000 0x0 0x00001000>, /* dma registers */
> > + <0x00 0x40481000 0x0 0x000000f8>, /* ctrl registers */
> > + /*
> > + * RC configuration space, 4KB each for cfg0 and cfg1
> > + * at the end of the outbound memory map
> > + */
> > + <0x5f 0xffffe000 0x0 0x00002000>,
> > + <0x58 0x00000000 0x0 0x40000000>; /* 1GB EP addr space */
> > + reg-names = "dbi", "dbi2", "atu", "dma", "ctrl",
> > + "config", "addr_space";
> > + dma-coherent;
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + device_type = "pci";
> > + ranges =
> > + /*
> > + * downstream I/O, 64KB and aligned naturally just
> > + * before the config space to minimize fragmentation
> > + */
> > + <0x81000000 0x0 0x00000000 0x5f 0xfffe0000 0x0 0x00010000>,
>
> s/0x81000000/0x01000000
>
> since the 'relocatable' is irrelevant.
>
> > + /*
> > + * non-prefetchable memory, with best case size and
> > + * alignment
> > + */
> > + <0x82000000 0x0 0x00000000 0x58 0x00000000 0x7 0xfffe0000>;
>
> s/0x82000000/0x02000000
>
> And the PCI address really starts from 0x00000000? I don't think so.
I'm going to check why they set this value
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists