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]
Message-ID: <4b0981d08e558b8730ddde3cdee52797a4644e1d.camel@calian.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ