linux-kernel - Re: [PATCH 1/2] dt-bindings: net: rockchip-dwmac: add rk3568 xpcs compatible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3689593.Mh6RI2rZIc@diego>
Date:   Tue, 29 Nov 2022 11:22:28 +0100
From:   Heiko Stübner <heiko@...ech.de>
To:     Chukun Pan <amadeus@....edu.cn>,
        "David S . Miller" <davem@...emloft.net>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        David Wu <david.wu@...k-chips.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/2] dt-bindings: net: rockchip-dwmac: add rk3568 xpcs compatible

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@....edu.cn>
> >>> ---
> >>>  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