public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: vkoul@kernel.org, neil.armstrong@linaro.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, ciprianmarian.costea@oss.nxp.com,
	s32@nxp.com, p.zabel@pengutronix.de, linux@armlinux.org.uk,
	ghennadi.procopciuc@nxp.com, Ionut.Vicovan@nxp.com,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
	horms@kernel.org, Frank.li@nxp.com
Subject: Re: [PATCH 1/4 v2] dt-bindings: serdes: s32g: Add NXP serdes subsystem
Date: Mon, 9 Feb 2026 18:40:11 -0600	[thread overview]
Message-ID: <20260210004011.GA2188625-robh@kernel.org> (raw)
In-Reply-To: <20260203161917.1666696-2-vincent.guittot@linaro.org>

On Tue, Feb 03, 2026 at 05:19:14PM +0100, Vincent Guittot wrote:
> Describe the serdes subsystem available on the S32G platforms.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  .../bindings/phy/nxp,s32g-serdes.yaml         | 154 ++++++++++++++++++
>  1 file changed, 154 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> 
> diff --git a/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> new file mode 100644
> index 000000000000..fad34bee2a4f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> @@ -0,0 +1,154 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nxp,s32g-serdes.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP S32G2xxx/S32G3xxx SerDes PHY subsystem
> +
> +maintainers:
> +  - Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> +
> +description: |
> +  The SerDes subsystem on S32G SoC Family includes two types of PHYs:
> +    - One PCIe PHY: Supports various PCIe operation modes
> +    - Two Ethernet Physical Coding Sublayer (XPCS) controllers
> +
> +  SerDes operation mode selects the enabled PHYs and speeds. Clock frequency
> +  must be adapted accordingly. Below table describes all possible operation
> +  modes.
> +
> +  Mode  PCIe	XPCS0		XPCS1		PHY clock	Description
> +                SGMII		SGMII		  (MHz)
> +  -------------------------------------------------------------------------
> +  0	Gen3	N/A		N/A		100		Single PCIe
> +  1	Gen2	1.25Gbps	N/A		100		PCIe/SGMII
> +  2	Gen2	N/A		1.25Gbps	100		PCIe/SGMII
> +  3	N/A	1.25Gbps	1.25Gbps	100,125		SGMII
> +  4	N/A	3.125/1.25Gbps	3.125/1.25Gbps 	125		SGMII
> +  5	Gen2	N/A	        3.125Gbps     	100		PCIe/SGMII

Mixed tabs and spaces. Drop the tabs.

What's not clear to me is do you have 2 or 4 lanes?

> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - enum:
> +          - nxp,s32g2-serdes
> +      - items:
> +          - const: nxp,s32g3-serdes
> +          - const: nxp,s32g2-serdes
> +
> +  reg:
> +    maxItems: 4
> +
> +  reg-names:
> +    items:
> +      - const: ss_pcie
> +      - const: pcie_phy
> +      - const: xpcs0
> +      - const: xpcs1
> +
> +  clocks:
> +    minItems: 4
> +    maxItems: 5
> +
> +  clock-names:
> +    items:
> +      - const: axi
> +      - const: aux
> +      - const: apb
> +      - const: ref
> +      - const: ext
> +    minItems: 4
> +
> +  resets:
> +    maxItems: 2
> +
> +  reset-names:
> +    items:
> +      - const: serdes
> +      - const: pcie
> +
> +  nxp,sys-mode:
> +    $ref: /schemas/types.yaml#/definitions/uint32

       maximum: 5

Though isn't this redundant with the child nodes? You could use the 
standard 'phy-mode' property in each child.

> +    description: |
> +      SerDes operational mode. See above table for possible values.
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +patternProperties:
> +  '^serdes[0,1]_lane@[0,1]$':

Do you need to support serdes0_lane@0 and serdes1_lane@0 (or similar 
with "@1")? That's illegal as you have 2 nodes with the same address.

> +    description:
> +      Describe a serdes lane.
> +    type: object
> +
> +    properties:
> +      compatible:
> +        enum:
> +          - nxp,s32g2-serdes-pcie-phy
> +          - nxp,s32g2-serdes-xpcs

Seems like phy-mode would be sufficient. Are these separate blocks from 
the parent?

> +
> +      reg:
> +        maxItems: 1

Just 'maximum: 1' instead.

> +
> +      '#phy-cells':
> +        const: 0
> +
> +    required:
> +      - reg
> +      - compatible
> +
> +    unevaluatedProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - nxp,sys-mode
> +  - '#address-cells'
> +  - '#size-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    bus {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        serdes0: serdes@40480000 {
> +          compatible = "nxp,s32g3-serdes", "nxp,s32g2-serdes";
> +            reg = <0x0 0x40480000 0x0 0x108>,
> +                  <0x0 0x40483008 0x0 0x10>,
> +                  <0x0 0x40482000 0x0 0x800>,
> +                  <0x0 0x40482800 0x0 0x800>;
> +            reg-names = "ss_pcie", "pcie_phy", "xpcs0", "xpcs1";
> +            clocks = <&clks 1>,
> +                     <&clks 2>,
> +                     <&clks 3>,
> +                     <&clks 4>,
> +                     <&serdes_100_ext>;
> +            clock-names = "axi", "aux", "apb", "ref", "ext";
> +            resets = <&reset 9>,
> +                     <&reset 8>;
> +            reset-names = "serdes", "pcie";
> +            nxp,sys-mode = <1>;
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +            phy_pcie0: serdes0_lane@0 {
> +              compatible = "nxp,s32g2-serdes-pcie-phy";
> +              #phy-cells = <0>;
> +              reg = <0>;
> +            };
> +            phy_xpcs0_0: serdes0_lane@1 {
> +              compatible = "nxp,s32g2-serdes-xpcs";
> +              reg = <0>;
> +            };
> +        };
> +    };
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-02-10  0:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 16:19 [PATCH 0/4 v2] Serdes: s32g: Add support for serdes subsystem Vincent Guittot
2026-02-03 16:19 ` [PATCH 1/4 v2] dt-bindings: serdes: s32g: Add NXP " Vincent Guittot
2026-02-10  0:40   ` Rob Herring [this message]
2026-02-12  7:17     ` Vincent Guittot
2026-02-12 21:10       ` Rob Herring
2026-02-25 14:00         ` Vincent Guittot
2026-02-12 10:28     ` Russell King (Oracle)
2026-02-25 14:01       ` Vincent Guittot
2026-02-03 16:19 ` [PATCH 2/4 v2] phy: s32g: Add serdes subsystem phy Vincent Guittot
2026-02-03 16:19 ` [PATCH 3/4 v2] phy: s32g: Add serdes xpcs subsystem Vincent Guittot
2026-02-04 15:29   ` Russell King (Oracle)
2026-02-05 17:02     ` Vincent Guittot
2026-02-03 16:19 ` [PATCH 4/4 v2] MAINTAINERS: Add MAINTAINER for NXP S32G Serdes driver Vincent Guittot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260210004011.GA2188625-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=Frank.li@nxp.com \
    --cc=Ionut.Vicovan@nxp.com \
    --cc=ciprianmarian.costea@oss.nxp.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ghennadi.procopciuc@nxp.com \
    --cc=horms@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=neil.armstrong@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=s32@nxp.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox