netdev - Re: [PATCH net 1/7] net: axienet: Reset core before accessing MAC and wait for core ready

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 12 Jan 2022 16:46:10 +0000
From:   Robert Hancock <robert.hancock@...ian.com>
To:     "kuba@...nel.org" <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "radhey.shyam.pandey@...inx.com" <radhey.shyam.pandey@...inx.com>
Subject: Re: [PATCH net 1/7] net: axienet: Reset core before accessing MAC and
 wait for core ready

On Tue, 2022-01-11 at 19:24 -0800, Jakub Kicinski wrote:
> On Wed, 12 Jan 2022 00:30:33 +0000 Robert Hancock wrote:
> > On Tue, 2022-01-11 at 15:13 -0600, Robert Hancock wrote:
> > > In some cases where the Xilinx Ethernet core was used in 1000Base-X or
> > > SGMII modes, which use the internal PCS/PMA PHY, and the MGT
> > > transceiver clock source for the PCS was not running at the time the
> > > FPGA logic was loaded, the core would come up in a state where the
> > > PCS could not be found on the MDIO bus. To fix this, the Ethernet core
> > > (including the PCS) should be reset after enabling the clocks, prior to
> > > attempting to access the PCS using of_mdio_find_device.
> > > 
> > > Also, when resetting the device, wait for the PhyRstCmplt bit to be set
> > > in the interrupt status register before continuing initialization, to
> > > ensure that the core is actually ready. The MgtRdy bit could also be
> > > waited for, but unfortunately when using 7-series devices, the bit does
> > > not appear to work as documented (it seems to behave as some sort of
> > > link state indication and not just an indication the transceiver is
> > > ready) so it can't really be relied on.
> 
> Shouldn't these be two separate fixes?

Yeah, this could likely be broken up into 2 patches (or possibly 3).

-- 
Robert Hancock
Senior Hardware Designer, Calian Advanced Technologies
www.calian.com