From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org,
Paolo Abeni <pabeni@redhat.com>, Vinod Koul <vkoul@kernel.org>
Subject: Re: [PATCH net-next 0/8] net: stmmac: improve PCS support
Date: Mon, 16 Mar 2026 05:15:53 +0530 [thread overview]
Message-ID: <abdEscs44fU4kRag@oss.qualcomm.com> (raw)
In-Reply-To: <abQC7r38QLhSeadl@shell.armlinux.org.uk>
Hi Russell,
On Fri, Mar 13, 2026 at 12:28:30PM +0000, Russell King (Oracle) wrote:
> This series is the next of the three part series sorting out the PCS
> support in stmmac, building on part 2:
>
> net: stmmac: qcom-ethqos: further serdes reorganisation
>
> Similar patches have been posted previously. This series does away with
> the common SerDes PHY support, instead using a flag to indicate whether
> 2500Mbps mode is supported (STMMAC_FLAG_SERDES_SUPPORTS_2500M.) At this
> time, I have no plans to resurect the common SerDes PHY support - the
> generic PHY layer implementations are just too random to consider that,
> and I certainly do not want the extra work of fixing that.
>
> Changes from RFC v3:
> - only set default_an_inband if using SGMII/2500BASE-X mode.
>
I encountered two NULL pointer dereferences and had to add a few
workarounds to proceed with testing.
1. On QCS9100 Ride R3, the mdio subnode is only defined for ethernet0
(see lemans-ride-ethernet-aqr115c.dtsi). ethernet1 uses ethernet0's
MDIO bus, so plat_dat->mdio_bus_data is NULL for ethernet1. Therefore,
we get:
[ 9.205979] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
[ 9.221071] pc : qcom_ethqos_probe+0xc4/0x478 [dwmac_qcom_ethqos]
[ 9.221078] lr : qcom_ethqos_probe+0x7c/0x478 [dwmac_qcom_ethqos]
[ 9.221080] sp : ffff800081aa37f0
[ 9.221081] x29: ffff800081aa3860 x28: ffffcf84de69cfe8 x27: 0000000000000001
[ 9.221084] x26: 0000000000000000 x25: ffff0000b4577c80 x24: ffff0000818fd010
[ 9.221087] x23: ffff000ec7057628 x22: 0000000000000000 x21: ffffcf84ca2ce028
[ 9.221089] x20: ffff0000818fd000
[ 9.236975] x19: ffff0000b3301740 x18: 00000000ffffffff
[ 9.236977] x17: 0000000000000000 x16: ffffcf84dc4a5448 x15: ffff0000b3301ec5
[ 9.236980] x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101
[ 9.236982] x11: 7f7f7f7f7f7f7f7f x10: 00000000001305b0 x9 : 0000000000000000
[ 9.236984] x8 : ffff0000b3301780 x7 : 0000000000000000 x6 : 000000000000003f
[ 9.236986] x5 : 0000000000000040 x4 : 0000000000000000 x3 : ffff0000818fd210
[ 9.236988] x2 : 0000000000000017 x1 : 0000000000000000 x0 : 0000000000000001
[ 9.236991] Call trace:
[ 9.236991] qcom_ethqos_probe+0xc4/0x478 [dwmac_qcom_ethqos] (P)
[ 9.236994] platform_probe+0x5c/0xac
...
[ 9.343300] Code: 910a7000 f9400b21 f9010320 52800020 (39005420)
[ 9.343302] ---[ end trace 0000000000000000 ]---
I added the following workaround:
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -765,7 +767,10 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
case PHY_INTERFACE_MODE_SGMII:
ethqos->configure_func = ethqos_configure_sgmii;
plat_dat->mac_finish = ethqos_mac_finish_serdes;
- plat_dat->mdio_bus_data->default_an_inband = true;
+ if (plat_dat->mdio_bus_data)
+ plat_dat->mdio_bus_data->default_an_inband = true;
+ else
+ dev_err(dev, "plat_dat->mdio_bus_data is NULL");
break;
default:
dev_err(dev, "Unsupported phy mode %s\n",
2. After working around issue 1, I hit the following:
[ 27.822907] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 27.831944] Mem abort info:
[ 27.834832] ESR = 0x0000000086000006
[ 27.838693] EC = 0x21: IABT (current EL), IL = 32 bits
[ 27.844163] SET = 0, FnV = 0
[ 27.847320] EA = 0, S1PTW = 0
[ 27.850563] FSC = 0x06: level 2 translation fault
[ 27.855587] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000134b1c000
[ 27.862212] [0000000000000000] pgd=080000010185c403, p4d=080000010185c403, pud=0800000134884403, pmd=0000000000000000
[ 27.873107] Internal error: Oops: 0000000086000006 [#1] SMP
[ 28.001619] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
[ 28.008853] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 28.016001] pc : 0x0
[ 28.018259] lr : phylink_pcs_an_restart+0x50/0x5c
[ 28.023092] sp : ffff8000869fb900
...
[ 28.185967] ---[ end trace 0000000000000000 ]---
This occurs due to pl->pcs->ops->pcs_an_restart being NULL. I added
the following workaround:
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1026,7 +1026,8 @@ static void phylink_pcs_an_restart(struct phylink *pl)
if (pl->pcs && linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
pl->link_config.advertising) &&
phy_interface_mode_is_8023z(pl->link_config.interface) &&
- phylink_autoneg_inband(pl->act_link_an_mode))
+ phylink_autoneg_inband(pl->act_link_an_mode) &&
+ pl->pcs->ops->pcs_an_restart)
pl->pcs->ops->pcs_an_restart(pl->pcs);
}
3. With the recent VLAN filter changes in net-next, ndo_open takes a long
time to complete as vlan_restore_hw_rx_fltr() tries to write filters
for all 32 indices. This board previously timed out once, but now
times out for each index. This is a separate issue unrelated to this
series but I added the following workaround to rule out any timing
issues.
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c
@@ -158,7 +158,8 @@ static void vlan_restore_hw_rx_fltr(struct net_device *dev,
/* Extended Rx VLAN Filter Enable */
for (i = 0; i < hw->num_vlan; i++)
- vlan_write_filter(dev, hw, i, hw->vlan_filter[i]);
+ if (hw->vlan_filter[i])
+ vlan_write_filter(dev, hw, i, hw->vlan_filter[i]);
}
static void vlan_update_hash(struct mac_device_info *hw, u32 hash,
With the above workarounds in place, 2.5G works fine, but 1G (and 100M)
do not. With the RFC v1 series, only the 2.5G->1G speed change was
broken. With this series, the link does not come up at 1G at all.
Some observations from my failed attempt at debugging so far:
- No change in behaviour after adding the provisioning code in
aqr_gen4_config_init().
- Setting GMAC_AN_CTRL_RAN in dwmac_integrated_pcs_config() did not
help.
- After shifting to 1G, GMAC_AN_STATUS reads 0x00000008, i.e.,
BMSR_LSTATUS (bit 2) is clear.
Sharing logs for two 1G scenarios (net-next + this series + the three
workarounds above):
# Booting up with a 1G link
[ 8.730854] qcom-ethqos 23040000.ethernet: IRQ eth_wake_irq not found
[ 8.766778] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[ 8.780465] qcom-ethqos 23040000.ethernet: DWMAC4/5
[ 8.794253] qcom-ethqos 23040000.ethernet: DMA HW capability register supported
[ 8.794258] qcom-ethqos 23040000.ethernet: Active PHY interface: SGMII (2)
<snip>
[ 8.865690] qcom-ethqos 23040000.ethernet: Using 36/40 bits DMA host/device width
[ 8.865707] qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00 exceeds mask 0x00000f00), truncating
[ 10.860749] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 10.861119] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 10.861510] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 10.861906] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 10.871763] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 10.907513] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 10.921216] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 10.921220] qcom-ethqos 23040000.ethernet eth1: configuring for inband/2500base-x link mode
[ 10.921223] qcom-ethqos 23040000.ethernet eth1: major config, requested inband/2500base-x
[ 10.921226] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=01 phy=00
[ 10.921228] qcom-ethqos 23040000.ethernet eth1: major config, active inband/inband,an-disabled/2500base-x
[ 10.921230] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/none adv=00000000,00000000,00008000,0000e240 pause=04
No further messages appear after this point, and the link does not come
up at 1G.
# Switching from 2.5G to 1G
[ 8.368113] qcom-ethqos 23040000.ethernet: IRQ eth_wake_irq not found
[ 8.379601] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[ 8.392900] qcom-ethqos 23040000.ethernet: DWMAC4/5
[ 8.432379] qcom-ethqos 23040000.ethernet: DMA HW capability register supported
<snip>
[ 8.480319] qcom-ethqos 23040000.ethernet: Using 36/40 bits DMA host/device width
[ 8.488609] qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00 exceeds mask 0x00000f00), truncating
[ 11.192140] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 11.200567] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 11.216466] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 11.232393] qcom-ethqos 23040000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 11.250011] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[ 11.269722] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[ 11.286758] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[ 11.300593] qcom-ethqos 23040000.ethernet eth1: configuring for inband/2500base-x link mode
[ 11.300596] qcom-ethqos 23040000.ethernet eth1: major config, requested inband/2500base-x
[ 11.300599] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=01 phy=00
[ 11.316311] qcom-ethqos 23040000.ethernet eth1: major config, active inband/inband,an-disabled/2500base-x
[ 11.316317] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/none adv=00000000,00000000,00008000,0000e240 pause=04
[ 14.125773] qcom-ethqos 23040000.ethernet: PCS Link Up
[ 14.131081] qcom-ethqos 23040000.ethernet eth1: pcs link up
[ 14.147059] qcom-ethqos 23040000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control rx/tx
<link speed changed to 1G>
[ 25.868674] qcom-ethqos 23040000.ethernet: PCS Link Down
[ 25.874184] qcom-ethqos 23040000.ethernet eth1: pcs link down
[ 25.874745] qcom-ethqos 23040000.ethernet eth1: Link is Down
No further messages appear after "Link is Down".
I have been having some issues with the IQ9 EVK (QCA8081 PHY), so no
results to report for it yet.
Ayaan
next prev parent reply other threads:[~2026-03-15 23:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 12:28 [PATCH net-next 0/8] net: stmmac: improve PCS support Russell King (Oracle)
2026-03-13 12:28 ` [PATCH net-next 1/8] net: stmmac: add struct stmmac_pcs_info Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 2/8] net: stmmac: add support for reading inband SGMII status Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 3/8] net: stmmac: add BASE-X support to integrated PCS Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 4/8] net: stmmac: use integrated PCS for BASE-X modes Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 5/8] net: stmmac: qcom-ethqos: enable 2500BASE-X Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 6/8] net: stmmac: qcom-ethqos: enable inband mode for SGMII Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 7/8] net: stmmac: configure SGMII AN control according to phylink Russell King (Oracle)
2026-03-13 12:29 ` [PATCH net-next 8/8] net: stmmac: report PCS configuration changes Russell King (Oracle)
2026-03-13 18:42 ` Russell King (Oracle)
2026-03-15 23:45 ` Mohd Ayaan Anwar [this message]
2026-03-16 1:11 ` [PATCH net-next 0/8] net: stmmac: improve PCS support Russell King (Oracle)
2026-03-17 14:48 ` Russell King (Oracle)
2026-03-18 22:12 ` Mohd Ayaan Anwar
2026-03-19 0:35 ` Russell King (Oracle)
2026-03-19 9:24 ` Russell King (Oracle)
2026-03-19 10:09 ` Konrad Dybcio
2026-03-19 12:58 ` Russell King (Oracle)
2026-03-19 13:50 ` Konrad Dybcio
2026-03-19 15:11 ` Russell King (Oracle)
2026-03-23 20:23 ` Mohd Ayaan Anwar
2026-03-24 9:14 ` Russell King (Oracle)
2026-03-18 21:59 ` Mohd Ayaan Anwar
2026-03-16 13:51 ` Russell King (Oracle)
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=abdEscs44fU4kRag@oss.qualcomm.com \
--to=mohd.anwar@oss.qualcomm.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vkoul@kernel.org \
/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