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

[Coia Prant <coiaprant@gmail.com>]

On October 6, 2026 11:08:31 PM GMT+08:00, Rob Herring <robh@kernel.org> 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@kernel.org> 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@gmail.com>
>> >> ---
>> >>  .../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@gmail.com>
>> >> +
>> >> +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