[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230521131226.bxk4g5gstprrvngp@skbuf>
Date: Sun, 21 May 2023 16:12:26 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: David Epping <david.epping@...singlinkelectronics.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net 3/3] net: phy: mscc: enable VSC8501/2 RGMII RX clock
On Sun, May 21, 2023 at 03:35:12PM +0300, Vladimir Oltean wrote:
> Let's resolve that difference before the patches are merged, and write
> some correct comments.
>
> I agree that the datasheet is not clear, but I think that the RX_CLK
> output is enabled or not based on the strapping of the RCVRDCLK1 and
> RCVRDCLK2 pins. Coincidentally, these are also muxed with PHYADD1 and
> PHYADD2, so the default value of RX_CLK_DISABLE might depend on the
> PHY address (?!).
>
> What is your PHY address? Mine are 0x10 and 0x11 for the VSC8502 on my
> board.
>
> Not saying that the patch is wrong or that the resolution should be any
> different than it is. Just that it's clear we can't both be right, and
> my PHYs clearly work (re-tested just now).
>
> --
> pw-bot: changes-requested
Ah, no, I think the explanation is much simpler. I see the datasheet
mentions that "RX_CLK output disable" is a sticky bit, which means it
preserves its value across a reset.
In my case, it is the U-Boot driver which clears that setting, as part
of configuring RGMII delays.
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/phy/mscc.c#L1553
Powered by blists - more mailing lists