Am Dienstag, 29. November 2022, 10:59:34 CET schrieb Krzysztof Kozlowski: > On 29/11/2022 10:56, Heiko Stübner wrote: > > Am Dienstag, 29. November 2022, 09:49:08 CET schrieb Krzysztof Kozlowski: > >> On 29/11/2022 08:27, Chukun Pan wrote: > >>> The gmac of RK3568 supports RGMII/SGMII/QSGMII interface. > >>> This patch adds a compatible string for the required clock. > >>> > >>> Signed-off-by: Chukun Pan <amadeus@xxxxxxxxxx> > >>> --- > >>> Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 6 ++++++ > >>> 1 file changed, 6 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > >>> index 42fb72b6909d..36b1e82212e7 100644 > >>> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > >>> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml > >>> @@ -68,6 +68,7 @@ properties: > >>> - mac_clk_rx > >>> - aclk_mac > >>> - pclk_mac > >>> + - pclk_xpcs > >>> - clk_mac_ref > >>> - clk_mac_refout > >>> - clk_mac_speed > >>> @@ -90,6 +91,11 @@ properties: > >>> The phandle of the syscon node for the peripheral general register file. > >>> $ref: /schemas/types.yaml#/definitions/phandle > >>> > >>> + rockchip,xpcs: > >>> + description: > >>> + The phandle of the syscon node for the peripheral general register file. > >> > >> You used the same description as above, so no, you cannot have two > >> properties which are the same. syscons for GRF are called > >> "rockchip,grf", aren't they? > > > > Not necessarily :-) . > > OK, then description should have something like "...GRF for foo bar". Actually looking deeper in the TRM, having these registers "just" written to from the dwmac-glue-layer feels quite a bit like a hack. The "pcs" thingy referenced in patch2 actually looks more like a real device with its own section in the TRM and own iomem area. This pcs device then itself has some more settings stored in said pipe-grf. So this looks more like it wants to be an actual phy-driver. @Chukun Pan: plase take a look at something like https://elixir.bootlin.com/linux/latest/source/drivers/phy/mscc/phy-ocelot-serdes.c#L398 on how phy-drivers for ethernets could look like. Aquiring such a phy from the dwmac-glue and calling phy_set_mode after moving the xpcs_setup to a phy-driver shouldn't be too hard I think. The qsgmii/sgmii_pcs list of registers in the TRM alone already takes up 4 A4 pages, so while using the PCS as syscon and just writing some values into it might work now, this doesn't feel at all like a future-save handling. Heiko
