From: Jakub Kicinski <kuba@kernel.org>
To: coiaprant@gmail.com
Cc: Jakub Kicinski <kuba@kernel.org>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, heiko@sntech.de, vkoul@kernel.org,
maxime.chevallier@bootlin.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com,
prabhakar.mahadev-lad.rj@bp.renesas.com,
romain.gantois@bootlin.com, hkallweit1@gmail.com,
neil.armstrong@linaro.org, linux@armlinux.org.uk,
shawn.lin@rock-chips.com, david@ixit.cz, netdev@vger.kernel.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v4 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
Date: Sat, 12 Sep 2026 13:13:25 -0700 [thread overview]
Message-ID: <20260912201325.127009-1-kuba@kernel.org> (raw)
In-Reply-To: <20260907153713.2572547-7-coiaprant@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
This adds the RK3568 Synopsys DesignWare XPCS node (with four pcs-mii
sub-nodes) plus two 125 MHz fixed-clock nodes used as GMAC reference
clocks. The XPCS node and its sub-nodes are disabled by default and are
meant to be completed and enabled at the board level.
A couple of questions about the new nodes below.
> 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
> @@ -110,6 +110,51 @@ sata0: sata@fc000000 {
> status = "disabled";
> };
>
> + 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: Medium]
Does this node validate against the binding added earlier in the same
series? Documentation/devicetree/bindings/net/pcs/rockchip-dwxpcs.yaml
lists phys and phy-names unconditionally:
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- clocks
- clock-names
- phys
- phy-names
- power-domains
The node here supplies neither, and dt-validate does not skip nodes with
status = "disabled", so dtbs_check should report "'phys' is a required
property" and "'phy-names' is a required property" for every rk3568 dtb
that includes this dtsi.
At the tip of the series only rk3568-photonicat.dts fills them in:
&xpcs {
status = "okay";
phys = <&combphy2 PHY_TYPE_SGMII>;
phy-names = "serdes";
};
so rk3568-evb, rk3568-rock-3a, rk3568-roc-pc, rk3568-radxa-cm3j,
rk3568-wolfvision-pf5 and friends would still be missing them.
If which combphy carries SGMII is genuinely a board-level choice, should
phys/phy-names be moved out of the unconditional required: list in the
binding instead, or should the dtsi provide a default?
> +
> + xpcs_mii0: pcs-mii@0 {
> + reg = <0>;
> + status = "disabled";
> + };
[Severity: Low]
This isn't a bug, just a note for the record: at this commit there is no
in-tree consumer of "rockchip,rk3568-xpcs" or of the pcs-mii sub-nodes.
Both arrive later in the same series - xpcs_rk_of_ids in
drivers/net/pcs/pcs-xpcs-rk.c gains the compatible, and rk_pcs_init() in
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c parses pcs-handle and
calls xpcs_rk_create(). With the nodes disabled by default the
intermediate state looks harmless, so nothing needs changing here.
> +
> + xpcs_mii1: pcs-mii@1 {
> + reg = <1>;
> + status = "disabled";
> + };
> +
> + xpcs_mii2: pcs-mii@2 {
> + reg = <2>;
> + status = "disabled";
> + };
> +
> + xpcs_mii3: pcs-mii@3 {
> + reg = <3>;
> + status = "disabled";
> + };
> + };
> +
> + xpcs_gmac0_clk: xpcs-gmac0-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac0_xpcs_mii";
> + #clock-cells = <0>;
> + };
> +
> + xpcs_gmac1_clk: xpcs-gmac1-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac1_xpcs_mii";
> + #clock-cells = <0>;
> + };
[Severity: Low]
These two node names take the deprecated branch of the fixed-clock
$nodename schema. Documentation/devicetree/bindings/clock/fixed-clock.yaml
has:
$nodename:
anyOf:
- description:
Preferred name is 'clock-<freq>' with <freq> being the output
frequency as defined in the 'clock-frequency' property.
pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
- description: Any name allowed
deprecated: true
xpcs-gmac0-clock and xpcs-gmac1-clock do not match the preferred
pattern, so they land on the "Any name allowed" branch. Newer Rockchip
dtsi files use the preferred form already, for example rk3528.dtsi with
xin24m: clock-xin24m and gmac0_clk: clock-gmac50m.
Could these be named clock-xpcs-gmac0 and clock-xpcs-gmac1? The labels
xpcs_gmac0_clk / xpcs_gmac1_clk and all references would stay the same.
> pipe_phy_grf0: syscon@fdc70000 {
> compatible = "rockchip,rk3568-pipe-phy-grf", "syscon";
> reg = <0x0 0xfdc70000 0x0 0x1000>;
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: coiaprant@gmail.com
Cc: Jakub Kicinski <kuba@kernel.org>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, heiko@sntech.de, vkoul@kernel.org,
maxime.chevallier@bootlin.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com,
prabhakar.mahadev-lad.rj@bp.renesas.com,
romain.gantois@bootlin.com, hkallweit1@gmail.com,
neil.armstrong@linaro.org, linux@armlinux.org.uk,
shawn.lin@rock-chips.com, david@ixit.cz, netdev@vger.kernel.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v4 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
Date: Sat, 12 Sep 2026 13:13:25 -0700 [thread overview]
Message-ID: <20260912201325.127009-1-kuba@kernel.org> (raw)
In-Reply-To: <20260907153713.2572547-7-coiaprant@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
This adds the RK3568 Synopsys DesignWare XPCS node (with four pcs-mii
sub-nodes) plus two 125 MHz fixed-clock nodes used as GMAC reference
clocks. The XPCS node and its sub-nodes are disabled by default and are
meant to be completed and enabled at the board level.
A couple of questions about the new nodes below.
> 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
> @@ -110,6 +110,51 @@ sata0: sata@fc000000 {
> status = "disabled";
> };
>
> + 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: Medium]
Does this node validate against the binding added earlier in the same
series? Documentation/devicetree/bindings/net/pcs/rockchip-dwxpcs.yaml
lists phys and phy-names unconditionally:
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- clocks
- clock-names
- phys
- phy-names
- power-domains
The node here supplies neither, and dt-validate does not skip nodes with
status = "disabled", so dtbs_check should report "'phys' is a required
property" and "'phy-names' is a required property" for every rk3568 dtb
that includes this dtsi.
At the tip of the series only rk3568-photonicat.dts fills them in:
&xpcs {
status = "okay";
phys = <&combphy2 PHY_TYPE_SGMII>;
phy-names = "serdes";
};
so rk3568-evb, rk3568-rock-3a, rk3568-roc-pc, rk3568-radxa-cm3j,
rk3568-wolfvision-pf5 and friends would still be missing them.
If which combphy carries SGMII is genuinely a board-level choice, should
phys/phy-names be moved out of the unconditional required: list in the
binding instead, or should the dtsi provide a default?
> +
> + xpcs_mii0: pcs-mii@0 {
> + reg = <0>;
> + status = "disabled";
> + };
[Severity: Low]
This isn't a bug, just a note for the record: at this commit there is no
in-tree consumer of "rockchip,rk3568-xpcs" or of the pcs-mii sub-nodes.
Both arrive later in the same series - xpcs_rk_of_ids in
drivers/net/pcs/pcs-xpcs-rk.c gains the compatible, and rk_pcs_init() in
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c parses pcs-handle and
calls xpcs_rk_create(). With the nodes disabled by default the
intermediate state looks harmless, so nothing needs changing here.
> +
> + xpcs_mii1: pcs-mii@1 {
> + reg = <1>;
> + status = "disabled";
> + };
> +
> + xpcs_mii2: pcs-mii@2 {
> + reg = <2>;
> + status = "disabled";
> + };
> +
> + xpcs_mii3: pcs-mii@3 {
> + reg = <3>;
> + status = "disabled";
> + };
> + };
> +
> + xpcs_gmac0_clk: xpcs-gmac0-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac0_xpcs_mii";
> + #clock-cells = <0>;
> + };
> +
> + xpcs_gmac1_clk: xpcs-gmac1-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac1_xpcs_mii";
> + #clock-cells = <0>;
> + };
[Severity: Low]
These two node names take the deprecated branch of the fixed-clock
$nodename schema. Documentation/devicetree/bindings/clock/fixed-clock.yaml
has:
$nodename:
anyOf:
- description:
Preferred name is 'clock-<freq>' with <freq> being the output
frequency as defined in the 'clock-frequency' property.
pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
- description: Any name allowed
deprecated: true
xpcs-gmac0-clock and xpcs-gmac1-clock do not match the preferred
pattern, so they land on the "Any name allowed" branch. Newer Rockchip
dtsi files use the preferred form already, for example rk3528.dtsi with
xin24m: clock-xin24m and gmac0_clk: clock-gmac50m.
Could these be named clock-xpcs-gmac0 and clock-xpcs-gmac1? The labels
xpcs_gmac0_clk / xpcs_gmac1_clk and all references would stay the same.
> pipe_phy_grf0: syscon@fdc70000 {
> compatible = "rockchip,rk3568-pipe-phy-grf", "syscon";
> reg = <0x0 0xfdc70000 0x0 0x1000>;
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: coiaprant@gmail.com
Cc: Jakub Kicinski <kuba@kernel.org>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, heiko@sntech.de, vkoul@kernel.org,
maxime.chevallier@bootlin.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com,
prabhakar.mahadev-lad.rj@bp.renesas.com,
romain.gantois@bootlin.com, hkallweit1@gmail.com,
neil.armstrong@linaro.org, linux@armlinux.org.uk,
shawn.lin@rock-chips.com, david@ixit.cz, netdev@vger.kernel.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH net-next v4 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
Date: Sat, 12 Sep 2026 13:13:25 -0700 [thread overview]
Message-ID: <20260912201325.127009-1-kuba@kernel.org> (raw)
In-Reply-To: <20260907153713.2572547-7-coiaprant@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes
This adds the RK3568 Synopsys DesignWare XPCS node (with four pcs-mii
sub-nodes) plus two 125 MHz fixed-clock nodes used as GMAC reference
clocks. The XPCS node and its sub-nodes are disabled by default and are
meant to be completed and enabled at the board level.
A couple of questions about the new nodes below.
> 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
> @@ -110,6 +110,51 @@ sata0: sata@fc000000 {
> status = "disabled";
> };
>
> + 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: Medium]
Does this node validate against the binding added earlier in the same
series? Documentation/devicetree/bindings/net/pcs/rockchip-dwxpcs.yaml
lists phys and phy-names unconditionally:
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- clocks
- clock-names
- phys
- phy-names
- power-domains
The node here supplies neither, and dt-validate does not skip nodes with
status = "disabled", so dtbs_check should report "'phys' is a required
property" and "'phy-names' is a required property" for every rk3568 dtb
that includes this dtsi.
At the tip of the series only rk3568-photonicat.dts fills them in:
&xpcs {
status = "okay";
phys = <&combphy2 PHY_TYPE_SGMII>;
phy-names = "serdes";
};
so rk3568-evb, rk3568-rock-3a, rk3568-roc-pc, rk3568-radxa-cm3j,
rk3568-wolfvision-pf5 and friends would still be missing them.
If which combphy carries SGMII is genuinely a board-level choice, should
phys/phy-names be moved out of the unconditional required: list in the
binding instead, or should the dtsi provide a default?
> +
> + xpcs_mii0: pcs-mii@0 {
> + reg = <0>;
> + status = "disabled";
> + };
[Severity: Low]
This isn't a bug, just a note for the record: at this commit there is no
in-tree consumer of "rockchip,rk3568-xpcs" or of the pcs-mii sub-nodes.
Both arrive later in the same series - xpcs_rk_of_ids in
drivers/net/pcs/pcs-xpcs-rk.c gains the compatible, and rk_pcs_init() in
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c parses pcs-handle and
calls xpcs_rk_create(). With the nodes disabled by default the
intermediate state looks harmless, so nothing needs changing here.
> +
> + xpcs_mii1: pcs-mii@1 {
> + reg = <1>;
> + status = "disabled";
> + };
> +
> + xpcs_mii2: pcs-mii@2 {
> + reg = <2>;
> + status = "disabled";
> + };
> +
> + xpcs_mii3: pcs-mii@3 {
> + reg = <3>;
> + status = "disabled";
> + };
> + };
> +
> + xpcs_gmac0_clk: xpcs-gmac0-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac0_xpcs_mii";
> + #clock-cells = <0>;
> + };
> +
> + xpcs_gmac1_clk: xpcs-gmac1-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clk_gmac1_xpcs_mii";
> + #clock-cells = <0>;
> + };
[Severity: Low]
These two node names take the deprecated branch of the fixed-clock
$nodename schema. Documentation/devicetree/bindings/clock/fixed-clock.yaml
has:
$nodename:
anyOf:
- description:
Preferred name is 'clock-<freq>' with <freq> being the output
frequency as defined in the 'clock-frequency' property.
pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
- description: Any name allowed
deprecated: true
xpcs-gmac0-clock and xpcs-gmac1-clock do not match the preferred
pattern, so they land on the "Any name allowed" branch. Newer Rockchip
dtsi files use the preferred form already, for example rk3528.dtsi with
xin24m: clock-xin24m and gmac0_clk: clock-gmac50m.
Could these be named clock-xpcs-gmac0 and clock-xpcs-gmac1? The labels
xpcs_gmac0_clk / xpcs_gmac1_clk and all references would stay the same.
> pipe_phy_grf0: syscon@fdc70000 {
> compatible = "rockchip,rk3568-pipe-phy-grf", "syscon";
> reg = <0x0 0xfdc70000 0x0 0x1000>;
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-09-12 20:14 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 15:37 [PATCH net-next v4 00/10] net: pcs: add basic support for RK3568 XPCS Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 01/10] net: stmmac: move XPCS lifetime management to platform drivers Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 14:51 ` Coia Prant
2026-09-13 14:51 ` Coia Prant
2026-09-13 14:51 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 02/10] dt-bindings: phy: rockchip: naneng-combphy: add rockchip,sgmii-mac-sel property Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 03/10] phy: rockchip: naneng-combphy: add SGMII MAC selection for RK3568 Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 15:11 ` Coia Prant
2026-09-13 15:11 ` Coia Prant
2026-09-13 15:11 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 04/10] dt-bindings: net: pcs: add rockchip,rk3568-xpcs support Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 15:30 ` Coia Prant
2026-09-13 15:30 ` Coia Prant
2026-09-13 15:30 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 05/10] arm64: dts: rockchip: rk3568: add XPCS and fixed-clock nodes Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-08 15:39 ` sashiko-bot
2026-09-08 15:39 ` sashiko-bot
2026-09-12 20:13 ` Jakub Kicinski [this message]
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 15:47 ` Coia Prant
2026-09-13 15:47 ` Coia Prant
2026-09-13 15:47 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 06/10] net: pcs: xpcs: add ANRESTART support for SGMII link recovery Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-08 15:40 ` sashiko-bot
2026-09-08 15:40 ` sashiko-bot
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 15:58 ` Coia Prant
2026-09-13 15:58 ` Coia Prant
2026-09-13 15:58 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 07/10] net: pcs: xpcs: add Rockchip RK3568 platform glue driver Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-08 15:40 ` sashiko-bot
2026-09-08 15:40 ` sashiko-bot
2026-09-13 17:02 ` Coia Prant
2026-09-13 17:02 ` Coia Prant
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 17:00 ` Coia Prant
2026-09-13 17:00 ` Coia Prant
2026-09-13 17:00 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 08/10] net: stmmac: dwmac-rk: add SGMII support for RK3568 Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 17:54 ` Coia Prant
2026-09-13 17:54 ` Coia Prant
2026-09-13 17:54 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 09/10] arm64: dts: rockchip: rk3568-photonicat: enable SGMII LAN port Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-12 20:13 ` Jakub Kicinski
2026-09-13 18:05 ` Coia Prant
2026-09-13 18:05 ` Coia Prant
2026-09-13 18:05 ` Coia Prant
2026-09-07 15:37 ` [PATCH net-next v4 10/10] MAINTAINERS: add entry for Rockchip XPCS driver Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-07 15:37 ` Coia Prant
2026-09-12 20:14 ` [PATCH net-next v4 00/10] net: pcs: add basic support for RK3568 XPCS Jakub Kicinski
2026-09-12 20:14 ` Jakub Kicinski
2026-09-12 20:14 ` Jakub Kicinski
2026-09-12 20:33 ` Coia Prant
2026-09-12 20:33 ` Coia Prant
2026-09-12 20:33 ` 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=20260912201325.127009-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=coiaprant@gmail.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=heiko@sntech.de \
--cc=hkallweit1@gmail.com \
--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-renesas-soc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=neil.armstrong@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh@kernel.org \
--cc=romain.gantois@bootlin.com \
--cc=shawn.lin@rock-chips.com \
--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 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.