[<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