All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Coia Prant" <coiaprant@gmail.com>
Cc: neil.armstrong@linaro.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org,
	olteanv@gmail.com, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH net-next v3 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
Date: Wed, 02 Sep 2026 15:04:39 +0000	[thread overview]
Message-ID: <20260902150439.756D31F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260901150111.141037-6-coiaprant@gmail.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Low] DT Schema Validation Failure: Disabled 'xpcs' node lacks required properties
- [Low] DT Schema Validation Failure: 'status' property in 'pcs-mii' subnodes
- [Low] Missing Hardware Reset Property in XPCS node
- [Low] Incorrect Clock Modeling: Fake fixed-clock nodes for hardware clocks
--

commit eff2669bff2081bb72b25ba5712b66df2f70b9bf
Author: Coia Prant <coiaprant@gmail.com>
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes

This commit adds the XPCS device node and its associated pcs-mii sub-nodes
to the RK3568 device tree. It also introduces two fixed-clock nodes to serve
as reference clocks for the GMACs.

> 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: pcs@fda00000 {
> +		compatible = "rockchip,rk3568-xpcs";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x0 0xfda00000 0x0 0x200000>;
> +		clocks = <&cru PCLK_XPCS>, <&cru CLK_XPCS_EEE>;
> +		clock-names = "csr", "eee";
> +		power-domains = <&power RK3568_PD_PIPE>;
> +		status = "disabled";

[Severity: Low]
Will this cause make dtbs_check to emit validation warnings for boards that
include rk3568.dtsi without overriding the xpcs node? The
rockchip,rk3568-xpcs binding schema unconditionally requires phys and
phy-names at the root level, even when the node is disabled.

[Severity: Low]
Does the xpcs node accurately represent the hardware without a resets
property? The RK3568 hardware provides dedicated resets (like SRST_XPCS)
for this block. Omitting the resets property might leave the hardware
description incomplete, even if the current Linux driver does not actively
use it.

> +
> +		xpcs_mii0: pcs-mii@0 {
> +			reg = <0>;
> +			status = "disabled";

[Severity: Low]
Is the status property permitted in these pcs-mii subnodes? The
rockchip-dwxpcs.yaml schema uses additionalProperties: false for the
^pcs-mii@[0-3]$ pattern and does not explicitly allow the status property.
This might trigger another validation warning during make dtbs_check.

> +		};
[ ... ]
> +
> +	xpcs_gmac0_clk: xpcs-gmac0-clock {
> +		compatible = "fixed-clock";
> +		clock-frequency = <125000000>;

[Severity: Low]
Does modeling these 125 MHz reference clocks as standalone fixed-clock nodes
mask the true hardware dependency? Since these clocks are actually generated
by the XPCS/Combo PHY block, using dummy board-level clocks could hide the
real topology from the device tree, even if a power management race is
currently avoided by a device link in the MAC driver.

> +		clock-output-names = "clk_gmac0_xpcs_mii";
> +		#clock-cells = <0>;
> +	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901150111.141037-1-coiaprant@gmail.com?part=5

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

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Coia Prant" <coiaprant@gmail.com>
Cc: neil.armstrong@linaro.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org,
	olteanv@gmail.com, wsa+renesas@sang-engineering.com
Subject: Re: [PATCH net-next v3 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
Date: Wed, 02 Sep 2026 15:04:39 +0000	[thread overview]
Message-ID: <20260902150439.756D31F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260901150111.141037-6-coiaprant@gmail.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Low] DT Schema Validation Failure: Disabled 'xpcs' node lacks required properties
- [Low] DT Schema Validation Failure: 'status' property in 'pcs-mii' subnodes
- [Low] Missing Hardware Reset Property in XPCS node
- [Low] Incorrect Clock Modeling: Fake fixed-clock nodes for hardware clocks
--

commit eff2669bff2081bb72b25ba5712b66df2f70b9bf
Author: Coia Prant <coiaprant@gmail.com>
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes

This commit adds the XPCS device node and its associated pcs-mii sub-nodes
to the RK3568 device tree. It also introduces two fixed-clock nodes to serve
as reference clocks for the GMACs.

> 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: pcs@fda00000 {
> +		compatible = "rockchip,rk3568-xpcs";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x0 0xfda00000 0x0 0x200000>;
> +		clocks = <&cru PCLK_XPCS>, <&cru CLK_XPCS_EEE>;
> +		clock-names = "csr", "eee";
> +		power-domains = <&power RK3568_PD_PIPE>;
> +		status = "disabled";

[Severity: Low]
Will this cause make dtbs_check to emit validation warnings for boards that
include rk3568.dtsi without overriding the xpcs node? The
rockchip,rk3568-xpcs binding schema unconditionally requires phys and
phy-names at the root level, even when the node is disabled.

[Severity: Low]
Does the xpcs node accurately represent the hardware without a resets
property? The RK3568 hardware provides dedicated resets (like SRST_XPCS)
for this block. Omitting the resets property might leave the hardware
description incomplete, even if the current Linux driver does not actively
use it.

> +
> +		xpcs_mii0: pcs-mii@0 {
> +			reg = <0>;
> +			status = "disabled";

[Severity: Low]
Is the status property permitted in these pcs-mii subnodes? The
rockchip-dwxpcs.yaml schema uses additionalProperties: false for the
^pcs-mii@[0-3]$ pattern and does not explicitly allow the status property.
This might trigger another validation warning during make dtbs_check.

> +		};
[ ... ]
> +
> +	xpcs_gmac0_clk: xpcs-gmac0-clock {
> +		compatible = "fixed-clock";
> +		clock-frequency = <125000000>;

[Severity: Low]
Does modeling these 125 MHz reference clocks as standalone fixed-clock nodes
mask the true hardware dependency? Since these clocks are actually generated
by the XPCS/Combo PHY block, using dummy board-level clocks could hide the
real topology from the device tree, even if a power management race is
currently avoided by a device link in the MAC driver.

> +		clock-output-names = "clk_gmac0_xpcs_mii";
> +		#clock-cells = <0>;
> +	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901150111.141037-1-coiaprant@gmail.com?part=5

  reply	other threads:[~2026-09-02 15:04 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 15:01 [PATCH net-next v3 00/10] net: pcs: add basic support for RK3568 XPCS Coia Prant
2026-09-01 15:01 ` Coia Prant
2026-09-01 15:01 ` Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 01/10] net: stmmac: move XPCS lifetime management to platform drivers Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-02 22:23   ` Maxime Chevallier
2026-09-02 22:23     ` Maxime Chevallier
2026-09-02 22:23     ` Maxime Chevallier
2026-09-03  8:32   ` Maxime Chevallier
2026-09-03  8:32     ` Maxime Chevallier
2026-09-03  8:32     ` Maxime Chevallier
2026-09-03  8:51     ` Coia Prant
2026-09-03  8:51       ` Coia Prant
2026-09-03  8:51       ` Coia Prant
2026-09-03  8:58       ` Maxime Chevallier
2026-09-03  8:58         ` Maxime Chevallier
2026-09-03  8:58         ` Maxime Chevallier
2026-09-01 15:01 ` [PATCH net-next v3 02/10] dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 03/10] phy: rockchip: naneng-combphy: add SGMII MAC selection for RK3568 Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 04/10] dt-bindings: net: pcs: add rockchip,rk3568-xpcs support Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-02 15:04   ` sashiko-bot [this message]
2026-09-02 15:04     ` sashiko-bot
2026-09-01 15:01 ` [PATCH net-next v3 06/10] net: pcs: xpcs: add ANRESTART support for SGMII link recovery Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-02 15:04   ` sashiko-bot
2026-09-02 15:04     ` sashiko-bot
2026-09-01 15:01 ` [PATCH net-next v3 07/10] net: pcs: xpcs: add Rockchip RK3568 platform glue driver Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-02 15:04   ` sashiko-bot
2026-09-02 15:04     ` sashiko-bot
2026-09-03 10:15     ` Coia Prant
2026-09-03 10:15       ` Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 08/10] net: stmmac: dwmac-rk: add SGMII support for RK3568 Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-02 15:04   ` sashiko-bot
2026-09-02 15:04     ` sashiko-bot
2026-09-03  8:34   ` Maxime Chevallier
2026-09-03  8:34     ` Maxime Chevallier
2026-09-03  8:34     ` Maxime Chevallier
2026-09-03  8:38     ` Coia Prant
2026-09-03  8:38       ` Coia Prant
2026-09-03  8:38       ` Coia Prant
2026-09-03  8:44       ` Maxime Chevallier
2026-09-03  8:44         ` Maxime Chevallier
2026-09-03  8:44         ` Maxime Chevallier
2026-09-03  8:59   ` Maxime Chevallier
2026-09-03  8:59     ` Maxime Chevallier
2026-09-03  8:59     ` Maxime Chevallier
2026-09-01 15:01 ` [PATCH net-next v3 09/10] arm64: dts: rockchip: rk3568-photonicat: enable SGMII LAN port Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01 ` [PATCH net-next v3 10/10] MAINTAINERS: add entry for Rockchip XPCS driver Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-01 15:01   ` Coia Prant
2026-09-05 20:00 ` [PATCH net-next v3 00/10] net: pcs: add basic support for RK3568 XPCS Jakub Kicinski
2026-09-05 20:00   ` Jakub Kicinski
2026-09-05 20:00   ` Jakub Kicinski
2026-09-07 15:30   ` Coia Prant
2026-09-07 15:30     ` Coia Prant
2026-09-07 15:30     ` 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=20260902150439.756D31F00A3A@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 \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.