netdev - Re: [PATCH] net: axiemac: initialize PHY before device reset

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] [day] [month] [year] [list]

Date:   Thu, 17 Mar 2022 18:26:41 +0000
From:   Robert Hancock <robert.hancock@...ian.com>
To:     "andy.chiu@...ive.com" <andy.chiu@...ive.com>
CC:     "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "michal.simek@...inx.com" <michal.simek@...inx.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "greentime.hu@...ive.com" <greentime.hu@...ive.com>,
        "radhey.shyam.pandey@...inx.com" <radhey.shyam.pandey@...inx.com>
Subject: Re: [PATCH] net: axiemac: initialize PHY before device reset

On Fri, 2022-03-18 at 01:37 +0800, Andy Chiu wrote:
> Thanks for pointing that out.
> 
> Though it is weird, it should be safe to do that. The reset of the
> MDIO interface would not affect any r/w through the bus afterwards
> since the driver would re-initialize the MDIO interface whenever it
> uses `mdiobus_write()` or `mdiobus_read()` for bus transactions.
> However, some of the very first packet on the rx side might get
> processed incompletely since `phylink_of_phy_connect()` will
> eventually call `phy_resume()`, which brings the phy active earlier
> than the reset of the core.
> 
> The reason why we have this change in ordering is that the clock of
> our PCS/PMA PHY is sourced from the SGMII ref clock of the external
> PHY, which is not enabled by default. The only way to get the PCS/PMA
> PHY stable here is to start the clock (initialize the external PHY)
> before the reset takes place. We have limited clock sources on the
> vcu118 FPGA board, and this happens to be our way to configure it. I
> think it is a hack on both sw and hw, but still wonder if anyone under
> such hw configuration, if exist, would like to have the patch.

I haven't looked at the clock setup on the VCU118 in detail, but we have used a
setup with this Ethernet core on the ZCU102 board to feed one of the SFP cages.
In that case we used the Si570 USER_MGT clock to feed the PCS/PMA clock by
changing its clock frequency to 156.25 MHz and routing that to the Ethernet
mgt_clk with the core set to accept that frequency.

It looks like a similar clock input is available on VCU118, I'm not sure if you
can do something similar in your setup? Since I assume this is all hardware on
the standard VCU118 board, Xilinx should likely have some example design for
this setup, I'm not sure what that is using?

Likely using a fixed board clock rather than one from the PHY is better if
possible, as you don't have this issue of the clock dependency going backwards
up the chain..

> 
>                |<---ref clock-----|
> +----------+---^---+         +------+
> > Xilinx's |  PCS/ |         | Ti's |
> > Ethernet |  PMA  |--SGMII--| PHY  |
> >          |  PHY  |         |      |
> +----------+-------+         +------+
>       |--------|--- MDIO---------|
> 
> loop-in: radhey.shyam.pandey@...inx.com
> 
> Andy
> 
> 
> Andy
-- 
Robert Hancock
Senior Hardware Designer, Calian Advanced Technologies
www.calian.com