mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yongzhao Chen <yongzhao.derek@gmail.com>
To: Ziyang Huang <hzyitc@outlook.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	Andrew Lunn <andrew@lunn.ch>, 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
Subject: Re: [RFC PATCH net-next v3 4/5] net: dsa: qca8k: flag QCA8337 internal CPU PHYs for SmartSpeed
Date: Sun, 27 Sep 2026 17:35:58 +0200	[thread overview]
Message-ID: <20260927153558.2299-1-yongzhao.derek@gmail.com> (raw)
In-Reply-To: <SEYPR01MB58827E0D18ACC93AF98A4109C98E2@SEYPR01MB5882.apcprd01.prod.exchangelabs.com>

Hi Ziyang,

> Have you correct the DAC settings of the IPQ5018 PHY ?

Thank you for pointing this out. It turned out that the DAC values were
not being applied on my board.

The OpenWrt DTS for this board sets qcom,dac-preset-short-cable, but
ipq5018_config_init() passes the unshifted value 0x10 to
phy_modify_mmd() and at803x_debug_reg_mask() while the mask is
GENMASK(15, 8). As a result, the high byte is cleared instead of being
set to 0x10, and bit 4 of the low byte is set. The same code is in
net-next today. All my earlier A/B runs, including the ones I reported
to Andrew, were done with this code. I will send the DAC fix as a
separate patch.

With both writes changed to FIELD_PREP(IPQ5018_PHY_DAC_MASK, 0x10), I
repeated the A/B on the same board: six alternating warm boots with
identical kernel and rootfs contents. The only difference between the
two groups was whether SmartSpeed on the QCA8337 CPU PHY was left
enabled or disabled before its initial reset. I kept 0x10 and did not
try other values, given your warning. In all six boots the read-back
after the write was MDAC 0x6868 -> 0x1068 and EDAC 0x7800 -> 0x1000,
so the high byte was 0x10 and the low byte was preserved.

The result was the same as before:

- SmartSpeed left enabled: failed 3/3. PHY4's CTRL1000 read 0x0400,
  register 0x11 read 0x1030, and the CPU link did not come up.
- SmartSpeed disabled: 3/3 came up at 1 Gb/s.

So correcting the DAC values alone did not avoid the failure in this
setup. I don't think this rules the DAC out yet, though, because of the
ordering. In these boots the QCA8337 CPU PHY (PHY4) was reset at about
2.3 s, while the IPQ5018 PHY's config_init(), which writes the DAC
values, ran at about 40 s. For roughly 38 s PHY4 may have been
negotiating with an IPQ5018 PHY that still had its reset-default DAC
values. I have not yet measured when PHY4 first drops its 1000BASE-T
advertisement relative to the DAC write.

Do you know whether the vendor code has an ordering requirement here,
for example setting the IPQ5018 DAC before the switch-side PHY starts
autonegotiation, or restarting the link after the DAC has been set?
Any pointer would be much appreciated.

Thanks,
Yongzhao Chen

  reply	other threads:[~2026-09-27 15:36 UTC|newest]

Thread overview: 20+ 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
2026-09-28 12:40                         ` Andrew Lunn
2026-09-27  8:05   ` Ziyang Huang
2026-09-27 15:35     ` Yongzhao Chen [this message]
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=20260927153558.2299-1-yongzhao.derek@gmail.com \
    --to=yongzhao.derek@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=florian.fainelli@broadcom.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®