From: Yongzhao Chen <yongzhao.derek@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Vladimir Oltean <olteanv@gmail.com>,
Christian Marangi <ansuelsmth@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Ziyang Huang <hzyitc@outlook.com>,
George Moussalem <george.moussalem@outlook.com>
Subject: Re: [RFC PATCH net-next v3 4/5] net: dsa: qca8k: flag QCA8337 internal CPU PHYs for SmartSpeed
Date: Mon, 28 Sep 2026 08:57:58 +0200 [thread overview]
Message-ID: <20260928065758.5507-1-yongzhao.derek@gmail.com> (raw)
In-Reply-To: <20260927153616.2317-1-yongzhao.derek@gmail.com>
Hi Andrew,
Following up on the initialisation order, as promised. On this board
it was the cause, and the DT workaround is not needed.
The IPQ5018 GE PHY leaves reset in ipq5018_probe() and starts
autonegotiating with its reset defaults. Its LDO, EEE, MSE and DAC
settings are only written in ipq5018_config_init(), when stmmac
attaches the PHY on open, about 39 s later on this board. I sampled
both PHYs during that window. They resolved 1000BASE-T every 2.5 to 3 s
without getting link, and after about five attempts SmartSpeed
downshifted on both sides at the same moment: the IPQ5018 PHY's
CTRL1000 went 0x0200 -> 0x0000 and PHY4's 0x0600 -> 0x0400. The soft
reset at attach restores the IPQ5018 side, but nothing touches PHY4
again, so the CPU link never came up.
Applying the same analog settings in probe, right after the reset, and
restarting autonegotiation, fixed it with SmartSpeed left enabled on
the QCA8337: 3 of 3 warm boots came up at 1 Gb/s about 2.5 s after PHY4
was reset, against 0 of 3 without it. Both groups ran the same kernel
and rootfs, with the probe-time writes enabled by a private DT property.
The final patch was then checked on the same board over a first boot,
three reboots, three interface down/up cycles, three renegotiations, a
network restart and a 10 minute observation, all at 1 Gb/s with
SmartSpeed enabled. It is still one board, and I have not done a
power-cycle test on this kernel.
So I will not add the workaround property. I will send the at803x
change to net together with the DAC fix, and v4 of this series without
patches 4 and 5. George, I've Cc'd you since the at803x change touches
the IPQ5018 probe path you added.
Thanks,
Yongzhao
next prev parent reply other threads:[~2026-09-28 6:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 21:58 [RFC PATCH net-next v3 0/5] net: dsa: qca8k: add a QCA8337 CPU PHY consumer Yongzhao Chen
2026-09-23 21:58 ` [RFC PATCH net-next v3 1/5] net: dsa: pass PHY flags when connecting shared ports Yongzhao Chen
2026-09-23 21:58 ` [RFC PATCH net-next v3 2/5] net: dsa: qca8k: serialize CPU MAC pause during MTU changes Yongzhao Chen
2026-09-23 21:58 ` [RFC PATCH net-next v3 3/5] net: dsa: qca8k: support QCA8337 internal PHY CPU links Yongzhao Chen
2026-09-23 21:58 ` [RFC PATCH net-next v3 4/5] net: dsa: qca8k: flag QCA8337 internal CPU PHYs for SmartSpeed Yongzhao Chen
2026-09-24 2:51 ` Andrew Lunn
2026-09-24 23:48 ` Yongzhao Chen
2026-09-25 15:17 ` Andrew Lunn
2026-09-25 21:01 ` Yongzhao Chen
2026-09-25 21:26 ` Andrew Lunn
2026-09-26 8:21 ` Yongzhao Chen
2026-09-26 13:11 ` Andrew Lunn
2026-09-26 21:51 ` Yongzhao Chen
2026-09-27 14:48 ` Andrew Lunn
2026-09-27 15:36 ` Yongzhao Chen
2026-09-28 6:57 ` Yongzhao Chen [this message]
2026-09-27 8:05 ` Ziyang Huang
2026-09-27 15:35 ` Yongzhao Chen
2026-09-23 21:58 ` [RFC PATCH net-next v3 5/5] net: phy: qca83xx: disable SmartSpeed before resetting CPU PHYs Yongzhao Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260928065758.5507-1-yongzhao.derek@gmail.com \
--to=yongzhao.derek@gmail.com \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=george.moussalem@outlook.com \
--cc=hkallweit1@gmail.com \
--cc=hzyitc@outlook.com \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®