From: sashiko-bot@kernel.org
To: "Coia Prant" <coiaprant@gmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org,
neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
vkoul@kernel.org, olteanv@gmail.com, conor+dt@kernel.org
Subject: Re: [RFC PATCH 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
Date: Wed, 15 Jul 2026 19:14:51 +0000 [thread overview]
Message-ID: <20260715191452.4A4821F00A3F@smtp.kernel.org> (raw)
In-Reply-To: <20260714191341.690906-6-coiaprant@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Devicetree anti-pattern: dummy fixed-clock nodes used for internal SoC clocks and left unassigned.
- [Low] State mismatch: fixed-clock nodes are enabled by default despite commit message claims.
--
--- Patch [5]: [RFC PATCH 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes ---
commit b47e1fcebd43374d6431fc20ffa64a0397513d68
Author: Coia Prant <coiaprant@gmail.com>
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
The RK3568 SoC integrates a Synopsys DesignWare XPCS that provides
the Physical Coding Sublayer for 1000BASE-X, SGMII, and QSGMII
interfaces via its four MII ports. Add the XPCS device node and
its pcs-mii sub-nodes to the SoC device tree.
> Also add two fixed-clock nodes (xpcs_gmac0_clk and xpcs_gmac1_clk)
> providing the 125 MHz reference clock for the GMACs when operating
> with XPCS. These clocks are used as the assigned-clock-parents
> for the respective GMAC nodes.
[Severity: Low]
The commit message states these clocks are used as assigned-clock-parents
for the respective GMAC nodes, but the patch doesn't appear to add the
assigned-clock-parents properties to the gmac0 or gmac1 nodes. Are these
assignments missing?
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> index 3bc653f027f1f..989e164c0eb39 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
[ ... ]
> + xpcs_gmac0_clk: xpcs-gmac0-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac0_xpcs_mii";
> + #clock-cells = <0>;
> + };
[Severity: Low]
Should this internal SoC clock be modeled as a clock provider from the
generating XPCS IP node using #clock-cells, rather than using a dummy
fixed-clock?
Additionally, the commit message states "All nodes are left disabled by
default", but this node is missing the status = "disabled" property. Will
this leave the clock unconditionally enabled?
> +
> + xpcs_gmac1_clk: xpcs-gmac1-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac1_xpcs_mii";
> + #clock-cells = <0>;
> + };
[Severity: Low]
Similarly, does this node also need a status = "disabled" property to align
with the behavior described in the commit message?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714191341.690906-1-coiaprant@gmail.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-15 19:14 UTC|newest]
Thread overview: 36+ 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-15 21:39 ` Coia Prant
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
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 [this message]
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 21:23 ` Coia Prant
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=20260715191452.4A4821F00A3F@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