linux-kernel - Re: [PATCH v1 1/3] dts64: rk3568: drop pclk

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: <236548630.RelmrRfzIS@diego>
Date:   Mon, 17 Jan 2022 22:05:29 +0100
From:   Heiko Stübner <heiko@...ech.de>
To:     Frank Wunderlich <frank-w@...lic-files.de>,
        Peter Geis <pgwipeout@...il.com>
Cc:     Johan Jonker <jbx6244@...il.com>,
        Frank Wunderlich <linux@...web.de>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        devicetree <devicetree@...r.kernel.org>,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 1/3] dts64: rk3568: drop pclk_xpcs from gmac0

Am Montag, 17. Januar 2022, 19:26:27 CET schrieb Peter Geis:
> On Mon, Jan 17, 2022 at 6:59 AM Frank Wunderlich
> <frank-w@...lic-files.de> wrote:
> >
> > Hi
> >
> > > Gesendet: Montag, 17. Januar 2022 um 11:47 Uhr
> > > Von: "Johan Jonker" <jbx6244@...il.com>
> > > Hi Frank,
> > >
> > > Despite that the DT is hosted in the kernel tree
> > > DT and mainline kernel driver support are 2 separate things.
> > > PCLK_XPCS might be in use elsewhere.
> > >
> > > Given the link below pclk_xpcs is only needed for rk3568.
> > > Maybe gmac1 should have a PCLK_XPCS too, because one can select between
> > > them.
> > >
> > > ethernet: stmicro: stmmac: Add SGMII/QSGMII support for RK3568
> > > https://github.com/rockchip-linux/kernel/commit/1fc7cbfe9e227c700c692f1de3137914b3ea6ca6
> > >
> > > The original dtsi did have PCLK_XPCS in both nodes.
> > > https://github.com/rockchip-linux/kernel/blob/develop-4.19/arch/arm64/boot/dts/rockchip/rk3568.dtsi#L2121
> > > https://github.com/rockchip-linux/kernel/blob/develop-4.19/arch/arm64/boot/dts/rockchip/rk3568.dtsi#L1492
> > >
> > > Maybe fix the document or leave it as it is for now as long the driver
> > > isn't updated and someone has tested it.
> > > That's up to the DT maintainer.
> > >
> > > Johan
> >
> > as far as i understand, the PCLK_XPCS is part of the naneng combphy, which is not yet available in mainline.
> > Naneng driver needs some changes and imho this should be part of it (including change documentation). That also makes it clear why this clock is added.
> > But leaving an unused property with sideeffects is imho no good choice.
> >
> > So this was the easiest way to fix the dtbs_check. Else i got no usable result for it. Maybe adding it to Documentation is also easy, but have not yet looked into it as it currently unused from my POV.
> >
> > But i leave it as decision for Maintainer to drop this patch as it is not needed for my Board DTS.
> 
> As both the current submission of the combophy driver and the gmac
> driver do not support xpcs, I elected to remove the clock vice adding
> documentation for something which is not currently supported.
> This is especially true as it only leaked through for the gmac0 port,
> the gmac1 port is modeled to the current support level.
> 
> Once xpcs support is introduced, the clock can be added to the
> documentation and both controllers as part of the same patch series.
> 
> Do you concur, Heiko?

Did you see my own reply from some hours ago?
>From looking at the documentation I got the impression that the
pclk_xpcs is related to the separate qsgmii_pcs in the memory map.

So yes, I fully agree to dropping this clock from here and then adding
them to whatever ip block really needs it.


Heiko


> > > ===
> > >
> > > XPCS is also part of PD_PIPE.
> > > See Rockchip RK3568 TRM Part1 V1.0-20210111.pdf page 475.
> > > Please advise if the power-domain@...568_PD_PIPE does need a PCLK_XPCS
> > > fix or is PCLK_PIPE enough in combination with a PHY driver?
> > >
> > > PD_PIPE:
> > >
> > > BIU_PIPE
> > > USB3OTG
> > > PCIE20
> > > PCIE30
> > > SATA
> > > XPCS
> > >
> > >
> > >       power-domain@...568_PD_PIPE {
> > >               reg = <RK3568_PD_PIPE>;
> > >               clocks = <&cru PCLK_PIPE>;
> > >               pm_qos = <&qos_pcie2x1>,
> > >                        <&qos_pcie3x1>,
> > >                        <&qos_pcie3x2>,
> > >                        <&qos_sata0>,
> > >                        <&qos_sata1>,
> > >                        <&qos_sata2>,
> > >                        <&qos_usb3_0>,
> > >                        <&qos_usb3_1>;
> > >               #power-domain-cells = <0>;
> > >       };
> >
> > PD_PIPE is imho also part of Naneng. But more for usage as USB3/SATA/... phy. This is not part of Mainline too.
> >
> > But thanks for pointing.
> >
> > regards Frank
>