From: sashiko-bot@kernel.org
To: "Coia Prant" <coiaprant@gmail.com>
Cc: olteanv@gmail.com, devicetree@vger.kernel.org,
linux-phy@lists.infradead.org, vkoul@kernel.org, robh@kernel.org,
conor+dt@kernel.org, neil.armstrong@linaro.org
Subject: Re: [RFC PATCH 02/10] dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property
Date: Wed, 15 Jul 2026 19:14:48 +0000 [thread overview]
Message-ID: <20260715191449.437E11F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260714191341.690906-3-coiaprant@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Logical contradiction between the property's documented default value and the commit message's explicit configuration requirement.
- [Low] The `rockchip,sgmii-mac-sel` property is defined globally and not conditionally constrained to the RK3568 SoC.
--
--- Patch [2]: [RFC PATCH 02/10] dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property ---
commit 0d950b4055dd144fecf5059f16535f2c8d94b5d3
Author: Coia Prant <coiaprant@gmail.com>
dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property
This commit adds the "rockchip,sgmii-mac-sel" property to the Rockchip
Naneng combphy device tree binding. It allows selecting between GMAC0
and GMAC1 for the SGMII interface on the RK3568 SoC.
> This is necessary for boards such as the Ariaboard Photonicat, where
> the SGMII interface is connected to GMAC0 and needs to be explicitly
> configured.
[Severity: Medium]
Is it actually necessary to explicitly configure the property to 0 for
GMAC0?
The schema defines the default as 0, which implies that omitting the property
would naturally default the hardware to GMAC0. If explicit configuration is
required, does this mean the hardware or bootloader leaves the register at 1,
making the `default: 0` documented in the schema incorrect?
> diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
> index 379b08bd9e97a..6173192e31ab2 100644
> --- a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml
[ ... ]
> @@ -80,6 +80,13 @@ properties:
> description:
> Some additional pipe settings are accessed through GRF regs.
>
> + rockchip,sgmii-mac-sel:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1]
[Severity: Low]
Should this property be conditionally restricted to the RK3568 compatible
string?
Because it is defined in the top-level properties block, it will pass
validation for all other hardware variants (like RK3528 or RK3588) that do
not actually support SGMII. Could an `if-then` block in the `allOf` section
be used to set this property to false for compatibles other than
`rockchip,rk3568-naneng-combphy`?
> + default: 0
> + description:
> + Select gmac0 or gmac1 to be used as SGMII controller.
> +
> "#phy-cells":
> const: 1
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714191341.690906-1-coiaprant@gmail.com?part=2
next prev parent reply other threads:[~2026-07-15 19:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 19:08 [RFC PATCH 00/10] net-next: add basic support for RK3568 XPCS Coia Prant
2026-07-14 19:08 ` [RFC PATCH 01/10] net: stmmac: move XPCS lifetime management to platform drivers Coia Prant
2026-07-15 7:31 ` Maxime Chevallier
2026-07-15 8:17 ` Coia Prant
2026-07-15 8:44 ` Christian Marangi
2026-07-15 11:15 ` Maxime Chevallier
2026-07-15 16:09 ` Andrew Lunn
2026-07-14 19:08 ` [RFC PATCH 02/10] dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property Coia Prant
2026-07-15 19:14 ` sashiko-bot [this message]
2026-07-15 19:53 ` Coia Prant
2026-07-14 19:08 ` [RFC PATCH 03/10] phy: rockchip: naneng-combphy: add SGMII MAC selection for RK3568 Coia Prant
2026-07-15 19:14 ` sashiko-bot
2026-07-15 19:55 ` Coia Prant
2026-07-14 19:08 ` [RFC PATCH 04/10] dt-bindings: net: pcs: add rockchip,rk3568-xpcs binding Coia Prant
2026-07-15 19:14 ` sashiko-bot
2026-07-15 20:01 ` Coia Prant
2026-07-14 19:08 ` [RFC PATCH 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes Coia Prant
2026-07-15 19:14 ` sashiko-bot
2026-07-15 20:09 ` Coia Prant
2026-07-14 19:08 ` [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568 Coia Prant
2026-07-14 22:44 ` Andrew Lunn
2026-07-14 23:05 ` Coia Prant
2026-07-15 19:14 ` sashiko-bot
2026-07-15 20:19 ` Coia Prant
2026-07-14 19:08 ` [RFC PATCH 07/10] net: pcs: xpcs: add Rockchip RK3568 platform glue driver Coia Prant
2026-07-15 7:42 ` Maxime Chevallier
2026-07-15 7:57 ` Coia Prant
2026-07-15 16:18 ` Andrew Lunn
2026-07-15 19:14 ` sashiko-bot
2026-07-14 19:08 ` [RFC PATCH 08/10] net: stmmac: dwmac-rk: add SGMII support for RK3568 Coia Prant
2026-07-15 19:14 ` sashiko-bot
2026-07-15 20:33 ` Coia Prant
2026-07-14 19:08 ` [RFC PATCH 09/10] arm64: dts: rockchip: rk3568-photonicat: enable SGMII LAN port Coia Prant
2026-07-14 19:08 ` [RFC PATCH 10/10] MAINTAINERS: add entry for Rockchip XPCS driver Coia Prant
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=20260715191449.437E11F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=coiaprant@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@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 \
/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