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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20220111192439.44fb795e@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Tue, 11 Jan 2022 19:24:39 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Robert Hancock <robert.hancock@...ian.com>
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 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?