mbox series

[net-next,v2,0/3] net: mdio-ipq4019: fix wrong default MDC rate

Message ID 20240130003546.1546-1-ansuelsmth@gmail.com
Headers
Series net: mdio-ipq4019: fix wrong default MDC rate |

Message

Christian Marangi Jan. 30, 2024, 12:35 a.m. UTC 
  This was a long journey to arrive and discover this problem.

To not waste too much char, there is a race problem with PHY and driver
probe. This was observed with Aquantia PHY firmware loading.

With some hacks the race problem was workarounded but an interesting
thing was notice. It took more than a minute for the firmware to load
via MDIO.

This was strange as the same operation was done by UBoot in at max 5
second and the same data was loaded.

A similar problem was observed on a mtk board that also had an
Aquantia PHY where the load was very slow. It was notice that the cause
was the MDIO bus running at a very low speed and the firmware
was missing a property (present in mtk sdk) that set the right frequency
to the MDIO bus.

It was fun to find that THE VERY SAME PROBLEM is present on IPQ in a
different form. The MDIO apply internally a division to the feed clock
resulting in the bus running at 390KHz instead of 6.25Mhz.

Searching around the web for some documentation and some include and
analyzing the uboot codeflow resulted in the divider being set wrongly
at /256 instead of /16 as the value was actually never set.
Applying the value restore the original load time for the Aquantia PHY.

This series mainly handle this by adding support for the "clock-frequency"
property.

Changes v2:
- Use DIV_ROUND_UP
- Introduce logic to chose a default value for 802.3 spec 2.5MHz

Christian Marangi (3):
  dt-bindings: net: ipq4019-mdio: document now supported clock-frequency
  net: mdio: ipq4019: add support for clock-frequency property
  arm64: dts: qcom: ipq8074: add clock-frequency to MDIO node

 .../bindings/net/qcom,ipq4019-mdio.yaml       |  15 +++
 arch/arm64/boot/dts/qcom/ipq8074.dtsi         |   2 +
 drivers/net/mdio/mdio-ipq4019.c               | 109 +++++++++++++++++-
 3 files changed, 120 insertions(+), 6 deletions(-)

Comments

Jakub Kicinski Jan. 31, 2024, 1:40 a.m. UTC | #1 
On Tue, 30 Jan 2024 01:57:36 +0100 Christian Marangi wrote:
> > If we merge this via netdev, is a merge conflict likely? Any other
> > changes expected in this area, given the changes which might happen to
> > GCC soon, etc?
> > 
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> 
> Honestly I don't expect much to change here in the mdio node.
> 
> If it's a problem I can submit in a separate patch in linux-msm.

The arch maintainers usually prefer to take the DTS patches,
so if there isn't anything special here we should probably
default to that.
Jie Luo Feb. 5, 2024, 3:24 a.m. UTC | #2 
On 2/4/2024 11:22 PM, Andrew Lunn wrote:
> On Sun, Feb 04, 2024 at 05:59:10PM +0800, Jie Luo wrote:
>>
>>
>> On 1/30/2024 8:35 AM, Christian Marangi wrote:
>>> +
>>> +	/* If div is /256 assume nobody have set this value and
>>> +	 * try to find one MDC rate that is close the 802.3 spec of
>>> +	 * 2.5MHz
>>> +	 */
>>> +	for (div = 256; div >= 8; div /= 2) {
>>> +		/* Stop as soon as we found a divider that
>>> +		 * reached the closest value to 2.5MHz
>>> +		 */
>>> +		if (DIV_ROUND_UP(ahb_rate, div) > 2500000)
>>> +			break;
>>
>> Hi Christian,
>> Sorry for the delayed review.
>>
>> The MDIO hardware block supports higher frequency 6.25M and 12.5M,
>> Would you remove this 2.5MHZ limitation? On the IPQ platform, we
>> normally use 6.25MHZ.
> 
> 802.3 says the clock has a maximum of 2.5MHz. So this code is correct.
> 
> It is however O.K. to go faster, but since that breaks the standard,
> you need each board to indicate it knows all the devices on the bus do
> support higher speeds and its O.K. to break the standard. You indicate
> this by using the DT property in its .dts file. For an MDIO bus which
> is totally internal, you could however put the DT property in the SoC
> .dtsi file.
> 
>        Andrew

Understand it, Thanks Andrew.