Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jan Petrous (OSS)" <jan.petrous@oss.nxp.com>
Cc: vkoul@kernel.org, imx@lists.linux.dev, Frank.Li@kernel.org,
	wsa+renesas@sang-engineering.com, linux-phy@lists.infradead.org,
	olteanv@gmail.com, linux-pci@vger.kernel.org, robh@kernel.org,
	conor+dt@kernel.org, neil.armstrong@linaro.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH RFC v3 01/12] dt-bindings: phy: Add NXP S32G SerDes subsystem
Date: Sun, 20 Sep 2026 06:54:55 +0000	[thread overview]
Message-ID: <20260920065455.72D9F1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260919-s32g_serdes-v3-1-9d68868c1e89@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: missing required enforcement for phy@0 and phy@1 nodes
--

commit 9e2cce806a48312a639c54029d5a8b84871dace7
Author: Jan Petrous (OSS) <jan.petrous@oss.nxp.com>

dt-bindings: phy: Add NXP S32G SerDes subsystem

This commit introduces the device tree binding for the NXP S32G2/S32G3 SerDes
subsystem. It defines the hardware constraints for the combo PHY shared
between PCIe and DesignWare XPCS instances, and specifies that both lanes
must always be described in the device tree.

> 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 0000000000000..6343d01bfde45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml

[ ... ]

> +patternProperties:
> +  '^phy@[01]$':
> +    description: One SerDes lane. The unit address is the physical lane index.
> +    type: object
> +    additionalProperties: false
> +
> +    properties:

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - '#address-cells'
> +  - '#size-cells'

[Severity: Medium]
The commit message explicitly states "Both lanes must always be described, even
a lane the board does not wire out to a connector", but is the schema actually 
enforcing this?

The patternProperties block defines the schema for the lane child nodes, but it
only applies validation if those nodes are present. Because the phy@0 and phy@1
node names are missing from the top-level required list, it looks like a
device tree omitting them would silently pass dt_binding_check validation.

Since the driver will fail the probe with -EINVAL if the lanes are missing,
could these nodes be explicitly required in the schema to fully enforce the
stated hardware constraints?

> +
> +additionalProperties: false

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919-s32g_serdes-v3-0-9d68868c1e89@oss.nxp.com?part=1

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-09-20  6:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19  6:54 [PATCH RFC v3 00/12] Add support for the NXP S32G SerDes subsystem Jan Petrous via B4 Relay
2026-09-19  6:54 ` [PATCH RFC v3 01/12] dt-bindings: phy: Add " Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot [this message]
2026-09-19  6:54 ` [PATCH RFC v3 02/12] dt-bindings: net: nxp,s32-dwmac: Document pcs-handle Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 03/12] dt-bindings: PCI: nxp,s32g-pcie: Fix SerDes PHY phandle in example Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 04/12] net: pcs: add NXP SerDes XPCS shared core Jan Petrous via B4 Relay
2026-09-19 15:31   ` Maxime Chevallier
2026-09-19 16:31     ` Coia Prant
2026-09-20  6:54   ` sashiko-bot
2026-09-20 18:39   ` Andrew Lunn
2026-09-19  6:54 ` [PATCH RFC v3 05/12] net: pcs: Add NXP S32G XPCS driver Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-20 17:07   ` Andrew Lunn
2026-09-19  6:54 ` [PATCH RFC v3 06/12] phy: freescale: s32g: Add SerDes subsystem PHY Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 07/12] net: stmmac: dwmac-s32: Add SGMII support Jan Petrous via B4 Relay
2026-09-19 12:04   ` Maxime Chevallier
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 08/12] MAINTAINERS: Add NXP S32G SerDes and SerDes xPCS core entries Jan Petrous via B4 Relay
2026-09-19  6:54 ` [PATCH RFC v3 09/12] arm64: dts: s32g: Add SCMI reset controller Jan Petrous via B4 Relay
2026-09-20  6:54   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 10/12] arm64: dts: s32g: Add SerDes controller nodes Jan Petrous via B4 Relay
2026-09-20  6:55   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 11/12] arm64: dts: s32g: Add PCIe " Jan Petrous via B4 Relay
2026-09-20  6:55   ` sashiko-bot
2026-09-19  6:54 ` [PATCH RFC v3 12/12] arm64: dts: s32g: Add S32G3-RDB3 SerDes routing variants Jan Petrous via B4 Relay
2026-09-20  6:55   ` sashiko-bot

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=20260920065455.72D9F1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=jan.petrous@oss.nxp.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /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