Re: [PATCH net-next v10 1/6] dt-bindings: net: pcs: add rockchip,rk3568-xpcs support

[Coia Prant]

Coia Prant <coiaprant@xxxxxxxxx> 于2026年10月6日周二 23:52写道：
>
> On October 6, 2026 11:08:31 PM GMT+08:00, Rob Herring <robh@xxxxxxxxxx> wrote:
> >On Tue, Oct 06, 2026 at 09:59:49PM +0800, Coia Prant wrote:
> >> On October 6, 2026 9:24:28 PM GMT+08:00, Rob Herring <robh@xxxxxxxxxx> wrote:
> >> >On Tue, Oct 06, 2026 at 06:30:03AM +0800, Coia Prant wrote:
> >> >> Add device tree binding documentation for the Synopsys DesignWare
> >> >> XPCS integrated on the Rockchip RK3568 SoC.
> >> >>
> >> >> The XPCS is accessed over the APB3 bus and internally connected to
> >> >> a Naneng Combo SerDes PHY.  It supports 1000BASE-X, SGMII, and
> >> >> QSGMII modes, with four MII ports.
> >> >>
> >> >> The four MII ports are described as ethernet-pcs-mii@N child nodes,
> >> >> consumed by the Rockchip XPCS glue driver later in this series.
> >> >>
> >> >> phys and phy-names are required because dtbs_check only validates
> >> >> required properties for enabled nodes. The SerDes link is a board-level
> >> >> design choice (combphy1 on some boards, combphy2 on others), so these
> >> >> properties must be provided by the board device tree, not the SoC dtsi.
> >> >>
> >> >> The CRU reset lines (SRST_XPCS*) are intentionally not described: no
> >> >> in-tree user requests them, and bring-up relies on the PD_PIPE power
> >> >> domain, the SerDes PHY and the in-IP soft reset. They can be added
> >> >> later as optional without breaking ABI.
> >> >>
> >> >> Signed-off-by: Coia Prant <coiaprant@xxxxxxxxx>
> >> >> ---
> >> >>  .../net/pcs/rockchip,rk3568-xpcs.yaml         | 110 ++++++++++++++++++
> >> >>  1 file changed, 110 insertions(+)
> >> >>  create mode 100644 Documentation/devicetree/bindings/net/pcs/rockchip,rk3568-xpcs.yaml
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/net/pcs/rockchip,rk3568-xpcs.yaml b/Documentation/devicetree/bindings/net/pcs/rockchip,rk3568-xpcs.yaml
> >> >> new file mode 100644
> >> >> index 0000000000000..703fcff0e3f70
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/net/pcs/rockchip,rk3568-xpcs.yaml
> >> >> @@ -0,0 +1,110 @@
> >> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> >> +%YAML 1.2
> >> >> +---
> >> >> +$id: http://devicetree.org/schemas/net/pcs/rockchip,rk3568-xpcs.yaml#
> >> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> >> +
> >> >> +title: Rockchip RK3568 Synopsys DesignWare Ethernet PCS
> >> >> +
> >> >> +maintainers:
> >> >> +  - Coia Prant <coiaprant@xxxxxxxxx>
> >> >> +
> >> >> +description: |
> >> >> +  Rockchip RK3568 SoC integrates a Synopsys DesignWare Ethernet Physical
> >> >> +  Coding Sublayer (XPCS).
> >> >> +  The PCS provides an interface between the Media Access Control (MAC)
> >> >> +  and the Physical Medium Attachment (PMA) sublayer through a Media
> >> >> +  Independent Interface (GMII).
> >> >> +
> >> >> +  The XPCS is accessed over the APB3 bus and internally connected to a
> >> >> +  Naneng Combo SerDes PHY.
> >> >> +  It supports 1000BASE-X, SGMII and QSGMII modes.
> >> >> +
> >> >> +  The block contains four MII ports that can be individually enabled and
> >> >> +  routed to one of the Ethernet GMAC controllers via the pcs-handle
> >> >> +  property in the MAC device tree node.
> >> >> +
> >> >> +properties:
> >> >> +  compatible:
> >> >> +    const: rockchip,rk3568-xpcs
> >> >> +
> >> >> +  reg:
> >> >> +    maxItems: 1
> >> >> +
> >> >> +  "#address-cells":
> >> >> +    const: 1
> >> >> +
> >> >> +  "#size-cells":
> >> >> +    const: 0
> >> >> +
> >> >> +  clocks:
> >> >> +    items:
> >> >> +      - description: APB3 bus interface clock (clk_csr_i), required for register access
> >> >> +      - description: EEE clock (clk_eee_i), required for Energy Efficient Ethernet operation
> >> >> +
> >> >> +  clock-names:
> >> >> +    items:
> >> >> +      - const: csr
> >> >> +      - const: eee
> >> >> +
> >> >> +  phys:
> >> >> +    maxItems: 1
> >> >> +
> >> >> +  phy-names:
> >> >> +    const: serdes
> >> >
> >> >You don't really need phy-names if there is only 1 entry.
> >> >
> >> >> +
> >> >> +  power-domains:
> >> >> +    maxItems: 1
> >> >> +
> >> >> +patternProperties:
> >> >> +  "^ethernet-pcs-mii@[0-3]$":
> >> >> +    type: object
> >> >> +    description:
> >> >> +      One of the four MII ports of the XPCS. The port is linked to an
> >> >> +      Ethernet MAC controller via the pcs-handle property in the MAC's
> >> >> +      device tree node.
> >> >> +
> >> >> +    properties:
> >> >> +      reg:
> >> >> +        description: MII port number.
> >> >> +        enum: [0, 1, 2, 3]
> >> >> +
> >> >> +    required:
> >> >> +      - reg
> >> >
> >> >Why the child nodes? They don't contain anything.
> >> >
> >> >Perhaps that's due to pcs-handle not supporting arg cells to pass the
> >> >port number? That's about to change[1].
> >> >
> >> >Rob
> >> >
> >> >[1] https://github.com/devicetree-org/dt-schema/pull/198
> >>
> >> Hi Rob,
> >>
> >> Both points make sense.
> >>
> >> 1. I'll drop phy-names since there's only a single entry.
> >>
> >> 2. For the ethernet-pcs-mii child nodes: you're right that they only
> >>    contain 'reg'. The reason I used child nodes is because pcs-handle
> >>    arg cells are not available yet -- PR #198 is still open and in
> >>    RFC/change-request state.
> >>
> >>    The RZN1 MII converter binding does the same thing: it declares
> >>    MII ports as subnodes and references the PCS via pcs-handle, until
> >>    arg cells land.
> >>
> >>    So I'd like to keep the child nodes as a temporary workaround, and
> >>    I'll add a note in the binding that this can be simplified once
> >>    PR #198 is merged.
> >
> >Bindings are an ABI. You can't merge the binding then change it. Please
> >comment on the PR that you all need it.
> >
> >Rob
>
> Hi Rob,
>
> Understood on the ABI point, and I don't want to merge a binding we'd
> have to change later.
>
> Could I ask for your guidance on the practical path? This series is
> ready, and I'd like to get it into 7.4 if possible, since OpenWrt and
> other distros base their support on LTS kernels. Missing this window
> means a long wait for users.
>
> Given PR #198 is still open, I see these options:
>
> 1. Wait for PR #198, then use pcs-handle = <&xpcs 0>. My concern is that
>    I have no visibility into its timeline -- it could be weeks or much
>    longer -- and holding the whole binding on that is hard to plan
>    around.
>
> 2. Keep the child nodes as the final ABI, RZ/N1 style, no planned
>    migration.
>
> 3. Something else you'd prefer.
>
> Which would you recommend? If waiting is the right call, I'll do that,
> but I'd like to understand roughly how long PR #198 is expected to take.
>
> Thanks,
> Coia

Hi Rob,

Thanks for the feedback. I went back to the Rockchip OEM SDK to check how
this is actually wired up, and it confirms the MII port is not an
independent board-level configuration -- it follows the MAC the SGMII
link is routed to (GMAC0 -> port 0, GMAC1 -> port 1).

So I've dropped the ethernet-pcs-mii child nodes and the phy-names
property, and the glue driver now derives the MII port from the MAC id.
The binding no longer needs pcs-handle argument cells, so we don't have
to wait for PR #198.

I'll post the updated series on the 9th.

Thanks,
Coia