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  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]
Date:   Sun, 5 Jul 2020 14:45:02 +0000
From:   Andy Duan <>
To:     Sven Van Asbroeck <>,
        Fabio Estevam <>
CC:     Shawn Guo <>, Rob Herring <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        netdev <>,
        Sascha Hauer <>,
        Pengutronix Kernel Team <>,
        dl-linux-imx <>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        linux-kernel <>
Subject: RE: [EXT] Re: [PATCH v5 3/3] ARM: imx6plus: optionally enable
 internal routing of clk_enet_ref

From: Sven Van Asbroeck <>
> Hi Fabio, Andy,
> On Thu, Jul 2, 2020 at 6:29 PM Fabio Estevam <> wrote:
> >
> > With the device tree approach, I think that a better place to touch
> > GPR5 would be inside the fec driver.
> >
> Are we 100% sure this is the best way forward, though?
> All the FEC driver should care about is the FEC logic block inside the SoC. It
> should not concern itself with the way a SoC happens to bring a clock (PTP
> clock) to the input of the FEC logic block - that is purely a SoC implementation
> detail.

I also agree with that relates to SOC integration. 
> It makes sense to add fsl,stop-mode (= a GPR bit) to the FEC driver, as this bit
> is a logic input to the FEC block, which the driver needs to dynamically flip.
> But the PTP clock is different, because it's statically routed by the SoC.
> Maybe this problem needs a clock routing solution?
> Isn't there an imx6q plus clock mux we're not modelling?
>   enet_ref-o------>ext>---pad_clk--| \
>            |                       |M |----fec_ptp_clk
>            o-----------------------|_/
> Where M = mux controlled by GPR5[9]
> The issue here is that pad_clk is routed externally, so its parent could be any
> internal or external clock. I have no idea how to model this in the clock
> framework.
Don't consider it complex, GPR5[9] just select the rgmii gtx source from PAD or internal
GPR5[9] is cleared: PAD -> MAC gtx
GPR5[9] is set: Pll_enet -> MAC gtx
As you said, register one clock mux for the selection, assign the clock parent by board dts
file, but now current clock driver doesn't support GPR clock. 

Powered by blists - more mailing lists