Thread (29 messages) flat view 29 messages, 2 authors, 3d ago

Re: [PATCH net-next v4 09/10] arm64: dts: rockchip: rk3568-photonicat: enable SGMII LAN port

From: Coia Prant <hidden>
Date: 2026-09-13 18:05:50
Also in: linux-arm-kernel, linux-devicetree, linux-phy, linux-renesas-soc, linux-rockchip, lkml

Jakub Kicinski [off-list ref] 于2026年9月13日周日 04:13写道:
quoted
@@ -242,6 +243,7 @@ &combphy1 {

 &combphy2 {
      status = "okay";
+     rockchip,sgmii-mac-sel = <0>;
 };
[Severity: Low]
The changelog says:

  "Enable combphy2 with rockchip,sgmii-mac-sel = <0> to route the SGMII
   interface to GMAC0."

Is that description accurate?  In the baseline the node already reads:

  &combphy2 {
          status = "okay";
  };

so the only new thing here is the rockchip,sgmii-mac-sel property.  Could
the wording be adjusted to say the property is added to an already enabled
combphy2?
You're right. combphy2 is already status = "okay" in the baseline; this
patch only adds the rockchip,sgmii-mac-sel property to it. I'll fix the
wording to say the property is added to an already-enabled combphy2.
[Severity: Low]
This isn't a bug, but the new properties do not follow the ordering used by
the rest of this file, where properties come roughly alphabetically and
status is last.  Here rockchip,sgmii-mac-sel lands after status, in &gmac0
below pcs-handle comes before managed, and in the new &xpcs override status
is first with phys/phy-names after it.  Compare the existing &gmac1
override, which ends with status = "okay";.  Could these be reordered?
I'll reorder the properties to follow the file's convention (roughly
alphabetical, with status last)
quoted
@@ -350,6 +391,25 @@ rgmii_phy: ethernet-phy@3 {
              reset-gpios = <&gpio4 RK_PC0 GPIO_ACTIVE_LOW>;
              rx-internal-delay-ps = <1500>;
              tx-internal-delay-ps = <1500>;
+
+             leds {
+                     #address-cells = <1>;
+                     #size-cells = <0>;
+
+                     led@1 {
+                             reg = <1>;
+                             color = <LED_COLOR_ID_AMBER>;
+                             function = LED_FUNCTION_WAN;
+                             default-state = "keep";
+                     };
+
+                     led@2 {
+                             reg = <2>;
+                             color = <LED_COLOR_ID_GREEN>;
+                             function = LED_FUNCTION_WAN;
+                             default-state = "keep";
+                     };
+             };
      };
 };
[Severity: Low]
This hunk describes the LEDs of the pre-existing RGMII WAN PHY on &mdio1,
which is already functional and unaffected by the SGMII enablement.  The
changelog justifies it only with:

  "Also add LED configuration for the existing RGMII PHY on mdio1 for
   consistency."

Would it be preferable to split this into its own patch, so this commit
contains only the SGMII LAN port enablement?
The LED configuration for both PHYs is kept in this patch because the
two PHYs are the same Motorcomm family wired identically on this board,
and describing them together keeps the two mdio nodes consistent. The
change is purely descriptive and does not affect the SGMII enablement.

That said, if you prefer it split out, I can move the mdio1 LED
description into a separate patch in v4.
quoted
@@ -586,3 +646,13 @@ &xin32k {
      pinctrl-names = "default";
      pinctrl-0 = <&clk32k_out1>;
 };
+
+&xpcs {
+     status = "okay";
+     phys = <&combphy2 PHY_TYPE_SGMII>;
+     phy-names = "serdes";
+};
[Severity: Medium]
Should phys/phy-names live in rk3568.dtsi rather than in each board file?

The binding lists them as required properties of the XPCS node:

  Documentation/devicetree/bindings/net/pcs/rockchip-dwxpcs.yaml
  required:
    - compatible
    - reg
    - "#address-cells"
    - "#size-cells"
    - clocks
    - clock-names
    - phys
    - phy-names
    - power-domains

but the SoC node in arch/arm64/boot/dts/rockchip/rk3568.dtsi has neither:

  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";

Does this mean every rk3568 dtb reports pcs@fda00000 as missing the required
phys and phy-names under make CHECK_DTBS=y, including boards that do not
enable the XPCS?

The XPCS to combphy2 connection is internal to the SoC, so each board that
enables it will have to repeat the same phandle, as this patch does.  Could
phys = <&combphy2 PHY_TYPE_SGMII>; and phy-names = "serdes"; be moved into
the dtsi node instead?
As replied in the earlier patch, the SerDes connection is board-specific
(some boards use combphy1 for SGMII, others use combphy2), so it cannot
be moved into rk3568.dtsi.

Best,
Coia
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help