drivers/net/phy/qcom/qca808x.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
Add support for rate matching to the QCA8081 PHY driver to correctly
report its capabilities. Some boards[0][1] with this PHY currently
report support only for 2.5G.
Implement the .get_rate_matching callback to allow phylink to determine
the actual PHY capabilities and report them accurately.
Before:
# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: 2500baseT/Full
Supported pause frame use: Symmetric Receive-only
...
After:
# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
...
[0] https://lore.kernel.org/all/20250905192350.1223812-3-umang.chheda@oss.qualcomm.com/
[1] https://lore.kernel.org/all/20250908-lemans-evk-bu-v4-12-5c319c696a7d@oss.qualcomm.com/
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
drivers/net/phy/qcom/qca808x.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/phy/qcom/qca808x.c b/drivers/net/phy/qcom/qca808x.c
index 8eb51b1a006c4c68ddce26c97d7d4f87a68158b0..9d9e93d2fa8f57b1535bc83e169eb011ae549040 100644
--- a/drivers/net/phy/qcom/qca808x.c
+++ b/drivers/net/phy/qcom/qca808x.c
@@ -643,6 +643,15 @@ static void qca808x_get_phy_stats(struct phy_device *phydev,
qcom_phy_get_stats(stats, priv->hw_stats);
}
+static int qca808x_get_rate_matching(struct phy_device *phydev,
+ phy_interface_t iface)
+{
+ if (iface == PHY_INTERFACE_MODE_2500BASEX)
+ return RATE_MATCH_PAUSE;
+
+ return RATE_MATCH_NONE;
+}
+
static struct phy_driver qca808x_driver[] = {
{
/* Qualcomm QCA8081 */
@@ -674,6 +683,7 @@ static struct phy_driver qca808x_driver[] = {
.led_polarity_set = qca808x_led_polarity_set,
.update_stats = qca808x_update_stats,
.get_phy_stats = qca808x_get_phy_stats,
+ .get_rate_matching = qca808x_get_rate_matching,
}, };
module_phy_driver(qca808x_driver);
---
base-commit: 5adf6f2b9972dbb69f4dd11bae52ba251c64ecb7
change-id: 20250912-qca808x_rate_match-570d44f510b2
Best regards,
--
Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>On Sun, Sep 14, 2025 at 08:36:48PM +0530, Mohd Ayaan Anwar wrote:
> Add support for rate matching to the QCA8081 PHY driver to correctly
> report its capabilities. Some boards[0][1] with this PHY currently
> report support only for 2.5G.
>
> Implement the .get_rate_matching callback to allow phylink to determine
> the actual PHY capabilities and report them accurately.
Sorry, but this is incorrect.
The PHY does not support rate matching, but switches between SGMII
and 2500BASE-X depending on the negotiated speed according to the code:
static void qca808x_fill_possible_interfaces(struct phy_device *phydev)
{
unsigned long *possible = phydev->possible_interfaces;
__set_bit(PHY_INTERFACE_MODE_SGMII, possible);
if (!qca808x_is_1g_only(phydev))
__set_bit(PHY_INTERFACE_MODE_2500BASEX, possible);
}
static int qca808x_read_status(struct phy_device *phydev)
{
...
if (phydev->link) {
if (phydev->speed == SPEED_2500)
phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
else
phydev->interface = PHY_INTERFACE_MODE_SGMII;
} else {
The driver certainly does not support rate-matching, even if the PHY
can support it, and even with your patch. All you are doing is making
ethtool suggest that other speeds are supported, but I think you'll
find that if the PHY negotiates those speeds, it won't work.
So, the bug is likely elsewhere, or your ethernet MAC doesn't support
SGMII and you need to add complete support for rate-matching to the
driver.
Please enable phylink debugging and send the kernel messages so I can
see what's going on.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Sun, Sep 14, 2025 at 07:10:36PM +0100, Russell King (Oracle) wrote:
> On Sun, Sep 14, 2025 at 08:36:48PM +0530, Mohd Ayaan Anwar wrote:
> > Add support for rate matching to the QCA8081 PHY driver to correctly
> > report its capabilities. Some boards[0][1] with this PHY currently
> > report support only for 2.5G.
> >
> > Implement the .get_rate_matching callback to allow phylink to determine
> > the actual PHY capabilities and report them accurately.
>
> Sorry, but this is incorrect.
>
> The PHY does not support rate matching, but switches between SGMII
> and 2500BASE-X depending on the negotiated speed according to the code:
>
> static void qca808x_fill_possible_interfaces(struct phy_device *phydev)
> {
> unsigned long *possible = phydev->possible_interfaces;
>
> __set_bit(PHY_INTERFACE_MODE_SGMII, possible);
>
> if (!qca808x_is_1g_only(phydev))
> __set_bit(PHY_INTERFACE_MODE_2500BASEX, possible);
> }
>
> static int qca808x_read_status(struct phy_device *phydev)
> {
> ...
> if (phydev->link) {
> if (phydev->speed == SPEED_2500)
> phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
> else
> phydev->interface = PHY_INTERFACE_MODE_SGMII;
> } else {
>
> The driver certainly does not support rate-matching, even if the PHY
> can support it, and even with your patch. All you are doing is making
> ethtool suggest that other speeds are supported, but I think you'll
> find that if the PHY negotiates those speeds, it won't work.
>
Weirdly, I was able to test both 1G and 2.5G with my patch. Could this
be because the driver is already deviating from the standard in other
areas?
> So, the bug is likely elsewhere, or your ethernet MAC doesn't support
> SGMII and you need to add complete support for rate-matching to the
> driver.
>
I tried setting phy-mode=sgmii in the Devicetree and I am able to get 1G
and lower speeds to work.
> Please enable phylink debugging and send the kernel messages so I can
> see what's going on.
>
Filtered logs (without my patch):
[ 7.937871] qcom-ethqos 23040000.ethernet: IRQ eth_wake_irq not found
[ 7.944581] qcom-ethqos 23040000.ethernet: IRQ eth_lpi not found
[ 7.953753] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[ 7.960927] qcom-ethqos 23040000.ethernet: DWMAC4/5
[ 7.966049] qcom-ethqos 23040000.ethernet: DMA HW capability register supported
[ 7.973564] qcom-ethqos 23040000.ethernet: RX Checksum Offload Engine supported
[ 7.981073] qcom-ethqos 23040000.ethernet: TX Checksum insertion supported
[ 7.988139] qcom-ethqos 23040000.ethernet: TSO supported
[ 7.993603] qcom-ethqos 23040000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[ 8.001654] qcom-ethqos 23040000.ethernet: Enabled L3L4 Flow TC (entries=8)
[ 8.008817] qcom-ethqos 23040000.ethernet: Enabled RFS Flow TC (entries=10)
[ 8.008819] qcom-ethqos 23040000.ethernet: Enabling HW TC (entries=128, max_off=64)
[ 8.008821] qcom-ethqos 23040000.ethernet: TSO feature enabled
[ 8.008822] qcom-ethqos 23040000.ethernet: SPH feature enabled
[ 8.008824] qcom-ethqos 23040000.ethernet: Using 36/40 bits DMA host/device width
[ 8.243500] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 8.253778] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-1
[ 8.261991] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-2
[ 8.262527] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-3
[ 8.348697] qcom-ethqos 23040000.ethernet eth0: PHY stmmac-0:1c uses interfaces 4,23, validating 23
[ 8.358304] qcom-ethqos 23040000.ethernet eth0: interface 23 (2500base-x) rate match none supports 6,13-14,47
[ 8.368589] qcom-ethqos 23040000.ethernet eth0: PHY [stmmac-0:1c] driver [Qualcomm QCA8081] (irq=POLL)
[ 8.368595] qcom-ethqos 23040000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,00006040 advertising 0000000,00000000,00008000,00006040
[ 8.381057] qcom-ethqos 23040000.ethernet eth0: Enabling Safety Features
[ 8.416398] qcom-ethqos 23040000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[ 8.425541] qcom-ethqos 23040000.ethernet eth0: registered PTP clock
[ 8.434778] qcom-ethqos 23040000.ethernet eth0: configuring for phy/2500base-x link mode
[ 8.446169] qcom-ethqos 23040000.ethernet eth0: major config, requested phy/2500base-x
[ 8.454323] qcom-ethqos 23040000.ethernet eth0: interface 2500base-x inband modes: pcs=00 phy=00
[ 8.463353] qcom-ethqos 23040000.ethernet eth0: major config, active phy/outband/2500base-x
[ 8.471939] qcom-ethqos 23040000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
[ 8.485780] 8021q: adding VLAN 0 to HW filter on device eth0
[ 8.489653] qcom-ethqos 23040000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 13.615848] qcom-ethqos 23040000.ethernet eth0: phy link up 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
[ 13.617924] qcom-ethqos 23040000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
// I changed the link partner speed to 1G here:
[ 74.031182] qcom-ethqos 23040000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[ 74.031773] qcom-ethqos 23040000.ethernet eth0: Link is Down
For reference, this board is using the same MAC as [0] which works
perfectly fine with the AQR115C PHY. I got the (wrong) idea to add
.get_rate_matching after comparing the two PHY drivers. The MAC driver
is stmmac/dwmac-qcom-ethqos.c
Ayaan
---
[0] https://elixir.bootlin.com/linux/v6.17-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
On Mon, Sep 15, 2025 at 02:25:36PM +0530, Mohd Ayaan Anwar wrote: > [ 7.937871] qcom-ethqos 23040000.ethernet: IRQ eth_wake_irq not found > [ 7.944581] qcom-ethqos 23040000.ethernet: IRQ eth_lpi not found > [ 7.953753] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52 > [ 7.960927] qcom-ethqos 23040000.ethernet: DWMAC4/5 So we're using stmmac as the MAC. > [ 8.348697] qcom-ethqos 23040000.ethernet eth0: PHY stmmac-0:1c uses interfaces 4,23, validating 23 > [ 8.358304] qcom-ethqos 23040000.ethernet eth0: interface 23 (2500base-x) rate match none supports 6,13-14,47 This shows that the PHY supports SGMII (4) and 2500base-X (23). However, as we only validate 2500base-X, this suggests stmmac doesn't support switching between SGMII and 2500base-X. > // I changed the link partner speed to 1G here: > [ 74.031182] qcom-ethqos 23040000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi > [ 74.031773] qcom-ethqos 23040000.ethernet eth0: Link is Down As the PHY will be programmed to only advertise 2500base-T, this is expected. > For reference, this board is using the same MAC as [0] which works > perfectly fine with the AQR115C PHY. I got the (wrong) idea to add > .get_rate_matching after comparing the two PHY drivers. The MAC driver > is stmmac/dwmac-qcom-ethqos.c AQR115C can be configured to support rate matching. What *exactly* is the setup with stmmac here? Do you have an external PCS to support 2500base-X, or are you using the stmmac internal PCS? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Sep 15, 2025 at 01:09:39PM +0100, Russell King (Oracle) wrote: > This shows that the PHY supports SGMII (4) and 2500base-X (23). However, > as we only validate 2500base-X, this suggests stmmac doesn't support > switching between SGMII and 2500base-X. > > What *exactly* is the setup with stmmac here? Do you have an external > PCS to support 2500base-X, or are you using the stmmac internal PCS? Internal PCS. But it's not really pure 2500base-X... I found an older thread for this exact MAC core [0], and it looks like we have an overclocked SGMII, i.e., 2500base-X without in-band signalling. Just wondering if registering a `.get_interfaces` callback in `dwmac-qcom-ethqos.c` and doing something like the following will be helpful? case PHY_INTERFACE_MODE_2500BASEX: __set_bit(PHY_INTERFACE_MODE_2500BASEX, interfaces); fallthrough; case PHY_INTERFACE_MODE_SGMII: __set_bit(PHY_INTERFACE_MODE_SGMII, interfaces); break; ... This should ensure that both SGMII and 2500base-X are validated, allowing switching between them. Ayaan --- [0] https://lore.kernel.org/netdev/4f642463-3a8c-4412-a007-42fb65c4276e@lunn.ch/
On Mon, Sep 15, 2025 at 08:24:26PM +0530, Mohd Ayaan Anwar wrote: > On Mon, Sep 15, 2025 at 01:09:39PM +0100, Russell King (Oracle) wrote: > > This shows that the PHY supports SGMII (4) and 2500base-X (23). However, > > as we only validate 2500base-X, this suggests stmmac doesn't support > > switching between SGMII and 2500base-X. > > > > What *exactly* is the setup with stmmac here? Do you have an external > > PCS to support 2500base-X, or are you using the stmmac internal PCS? > > Internal PCS. But it's not really pure 2500base-X... > I found an older thread for this exact MAC core [0], and it looks like > we have an overclocked SGMII, i.e., 2500base-X without in-band > signalling. > > Just wondering if registering a `.get_interfaces` callback in > `dwmac-qcom-ethqos.c` and doing something like the following will be > helpful? > > case PHY_INTERFACE_MODE_2500BASEX: > __set_bit(PHY_INTERFACE_MODE_2500BASEX, interfaces); > fallthrough; > case PHY_INTERFACE_MODE_SGMII: > __set_bit(PHY_INTERFACE_MODE_SGMII, interfaces); > break; > ... > > This should ensure that both SGMII and 2500base-X are validated, > allowing switching between them. So, this is something that has never worked with this hardware setup. I don't think we should rush to make it work. The stmmac internal PCS code is a mess, bypassing phylink. I had a patch series which addressed this a while back but it went nowhere, but I guess this is an opportunity to say "look, we need to get this sorted properly". I suspect this isn't going to be simple - stmmac does _not_ use phylink properly (I've been doing lots of cleanups to this driver over the last year or so to try and make the code more understandable so I can start addressing this deficiency) and there's still lots of work to be done. The way the "platform glue" drivers work is far from ideal, especially when it comes to switching interfaces. I'll try to post the stmmac PCS cleanup series in the coming few days, and it would be useful if you could give it whatever testing you can. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Sep 15, 2025 at 04:11:04PM +0100, Russell King (Oracle) wrote:
> On Mon, Sep 15, 2025 at 08:24:26PM +0530, Mohd Ayaan Anwar wrote:
> > On Mon, Sep 15, 2025 at 01:09:39PM +0100, Russell King (Oracle) wrote:
> > > This shows that the PHY supports SGMII (4) and 2500base-X (23). However,
> > > as we only validate 2500base-X, this suggests stmmac doesn't support
> > > switching between SGMII and 2500base-X.
> > >
> > > What *exactly* is the setup with stmmac here? Do you have an external
> > > PCS to support 2500base-X, or are you using the stmmac internal PCS?
> >
> > Internal PCS. But it's not really pure 2500base-X...
> > I found an older thread for this exact MAC core [0], and it looks like
> > we have an overclocked SGMII, i.e., 2500base-X without in-band
> > signalling.
> >
> > Just wondering if registering a `.get_interfaces` callback in
> > `dwmac-qcom-ethqos.c` and doing something like the following will be
> > helpful?
> >
> > case PHY_INTERFACE_MODE_2500BASEX:
> > __set_bit(PHY_INTERFACE_MODE_2500BASEX, interfaces);
> > fallthrough;
> > case PHY_INTERFACE_MODE_SGMII:
> > __set_bit(PHY_INTERFACE_MODE_SGMII, interfaces);
> > break;
> > ...
> >
> > This should ensure that both SGMII and 2500base-X are validated,
> > allowing switching between them.
>
> So, this is something that has never worked with this hardware setup.
> I don't think we should rush to make it work. The stmmac internal
> PCS code is a mess, bypassing phylink. I had a patch series which
> addressed this a while back but it went nowhere, but I guess this is
> an opportunity to say "look, we need to get this sorted properly".
>
> I suspect this isn't going to be simple - stmmac does _not_ use
> phylink properly (I've been doing lots of cleanups to this driver
> over the last year or so to try and make the code more
> understandable so I can start addressing this deficiency) and
> there's still lots of work to be done. The way the "platform glue"
> drivers work is far from ideal, especially when it comes to
> switching interfaces.
>
> I'll try to post the stmmac PCS cleanup series in the coming few
> days, and it would be useful if you could give it whatever
> testing you can.
... and it's been delayed because I've had to rework three of the
patch series I recently posted.
I did get some time late last night to read through the documentation
I have for one version of the dwmac which has optional PCS, and I'm
coming to the conclusion that the whole mac_interface vs phy_interface
thing is wrong in the driver.
My comment update which added this a few years ago:
/* MAC ----- optional PCS ----- SerDes ----- optional PHY ----- Media
* ^ ^
* mac_interface phy_interface
*
* mac_interface is the MAC-side interface, which may be the same
* as phy_interface if there is no intervening PCS. If there is a
* PCS, then mac_interface describes the interface mode between the
* MAC and PCS, and phy_interface describes the interface mode
* between the PCS and PHY.
*/
appears to be incorrect. It was based on just phylink knowledge and a
reasonable guess about what was going on with this driver. It seems
no one had any better ideas on exactly what mac_interface was trying
to describe.
Having looked at the information I now have, and referred back to the
psat code, it appears to me that what is actually going on here is
this:
MAC --- optional integrated PCS --- SerDes --- world (media or PHY)
^ ^
mac_interface phy_interface
TBI 1000base-X
It seems that TBI is used on the PCS output when talking to a SerDes
for 1000BASE-X or SGMII. RTBI is used with a PHY that can talk RTBI.
Considering just 2.5G and below, it seems to me that mac_interface
can be determined from phy_interface:
phy_interface mac_interface
SGMII TBI
1000BASE-X TBI
2500BASE-X TBI
RTBI RTBI
These are the "official" modes. There is also a seperate block that
is used for SMII and RGMII which the code treats as a PCS (partly
because it uses the same registers) so I'd throw into this:
phy_interface mac_interface
SMII SMII
RGMII* RGMII*
For every other phy_interface <= 2.5G, mac_interface is basically
not applicable, and we should be referring to phy_interface everywhere.
In fact, I can't see that mac_interface actually matters for most of
the driver. The only case I can see it matters is when the core
supports multiple interfaces, and needs to be configured appropriately
(which needs an entire core-wide reset if it changes.)
So, I'm going to propose at the very least selecting whether the driver
uses the PCS not based on mac_interface as the code currently does, but
on phy_interface (actually the interface passed by phylink.) That will
make phylink happier when stmmac is converted to phylink_pcs.
This means I need to spend some time reworking my series... and yay,
more patches to add to my already massive stack of stmmac patches. :/
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Sep 15, 2025 at 04:11:04PM +0100, Russell King (Oracle) wrote: > I'll try to post the stmmac PCS cleanup series in the coming few > days, and it would be useful if you could give it whatever > testing you can. Sure, sounds good. FWIW, I tested out a dirty version of the `.get_interfaces` change I metioned before and could validate both 1G and 2.5G. Ayaan
On Mon, Sep 15, 2025 at 02:25:42PM +0530, Mohd Ayaan Anwar wrote:
> On Sun, Sep 14, 2025 at 07:10:36PM +0100, Russell King (Oracle) wrote:
> > On Sun, Sep 14, 2025 at 08:36:48PM +0530, Mohd Ayaan Anwar wrote:
> > > Add support for rate matching to the QCA8081 PHY driver to correctly
> > > report its capabilities. Some boards[0][1] with this PHY currently
> > > report support only for 2.5G.
> > >
> > > Implement the .get_rate_matching callback to allow phylink to determine
> > > the actual PHY capabilities and report them accurately.
> >
> > Sorry, but this is incorrect.
> >
> > The PHY does not support rate matching, but switches between SGMII
> > and 2500BASE-X depending on the negotiated speed according to the code:
> >
> > static void qca808x_fill_possible_interfaces(struct phy_device *phydev)
> > {
> > unsigned long *possible = phydev->possible_interfaces;
> >
> > __set_bit(PHY_INTERFACE_MODE_SGMII, possible);
> >
> > if (!qca808x_is_1g_only(phydev))
> > __set_bit(PHY_INTERFACE_MODE_2500BASEX, possible);
> > }
> >
> > static int qca808x_read_status(struct phy_device *phydev)
> > {
> > ...
> > if (phydev->link) {
> > if (phydev->speed == SPEED_2500)
> > phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
> > else
> > phydev->interface = PHY_INTERFACE_MODE_SGMII;
> > } else {
> >
> > The driver certainly does not support rate-matching, even if the PHY
> > can support it, and even with your patch. All you are doing is making
> > ethtool suggest that other speeds are supported, but I think you'll
> > find that if the PHY negotiates those speeds, it won't work.
> >
>
> Weirdly, I was able to test both 1G and 2.5G with my patch. Could this
> be because the driver is already deviating from the standard in other
> areas?
>
> > So, the bug is likely elsewhere, or your ethernet MAC doesn't support
> > SGMII and you need to add complete support for rate-matching to the
> > driver.
> >
>
> I tried setting phy-mode=sgmii in the Devicetree and I am able to get 1G
> and lower speeds to work.
>
> > Please enable phylink debugging and send the kernel messages so I can
> > see what's going on.
> >
>
> Filtered logs (without my patch):
> [ 7.937871] qcom-ethqos 23040000.ethernet: IRQ eth_wake_irq not found
> [ 7.944581] qcom-ethqos 23040000.ethernet: IRQ eth_lpi not found
> [ 7.953753] qcom-ethqos 23040000.ethernet: User ID: 0x20, Synopsys ID: 0x52
> [ 7.960927] qcom-ethqos 23040000.ethernet: DWMAC4/5
> [ 7.966049] qcom-ethqos 23040000.ethernet: DMA HW capability register supported
> [ 7.973564] qcom-ethqos 23040000.ethernet: RX Checksum Offload Engine supported
> [ 7.981073] qcom-ethqos 23040000.ethernet: TX Checksum insertion supported
> [ 7.988139] qcom-ethqos 23040000.ethernet: TSO supported
> [ 7.993603] qcom-ethqos 23040000.ethernet: Enable RX Mitigation via HW Watchdog Timer
> [ 8.001654] qcom-ethqos 23040000.ethernet: Enabled L3L4 Flow TC (entries=8)
> [ 8.008817] qcom-ethqos 23040000.ethernet: Enabled RFS Flow TC (entries=10)
> [ 8.008819] qcom-ethqos 23040000.ethernet: Enabling HW TC (entries=128, max_off=64)
> [ 8.008821] qcom-ethqos 23040000.ethernet: TSO feature enabled
> [ 8.008822] qcom-ethqos 23040000.ethernet: SPH feature enabled
> [ 8.008824] qcom-ethqos 23040000.ethernet: Using 36/40 bits DMA host/device width
> [ 8.243500] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> [ 8.253778] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-1
> [ 8.261991] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-2
> [ 8.262527] qcom-ethqos 23040000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-3
> [ 8.348697] qcom-ethqos 23040000.ethernet eth0: PHY stmmac-0:1c uses interfaces 4,23, validating 23
> [ 8.358304] qcom-ethqos 23040000.ethernet eth0: interface 23 (2500base-x) rate match none supports 6,13-14,47
> [ 8.368589] qcom-ethqos 23040000.ethernet eth0: PHY [stmmac-0:1c] driver [Qualcomm QCA8081] (irq=POLL)
> [ 8.368595] qcom-ethqos 23040000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,00006040 advertising 0000000,00000000,00008000,00006040
> [ 8.381057] qcom-ethqos 23040000.ethernet eth0: Enabling Safety Features
> [ 8.416398] qcom-ethqos 23040000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
> [ 8.425541] qcom-ethqos 23040000.ethernet eth0: registered PTP clock
> [ 8.434778] qcom-ethqos 23040000.ethernet eth0: configuring for phy/2500base-x link mode
> [ 8.446169] qcom-ethqos 23040000.ethernet eth0: major config, requested phy/2500base-x
> [ 8.454323] qcom-ethqos 23040000.ethernet eth0: interface 2500base-x inband modes: pcs=00 phy=00
> [ 8.463353] qcom-ethqos 23040000.ethernet eth0: major config, active phy/outband/2500base-x
> [ 8.471939] qcom-ethqos 23040000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
> [ 8.485780] 8021q: adding VLAN 0 to HW filter on device eth0
> [ 8.489653] qcom-ethqos 23040000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> [ 13.615848] qcom-ethqos 23040000.ethernet eth0: phy link up 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
> [ 13.617924] qcom-ethqos 23040000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
>
> // I changed the link partner speed to 1G here:
> [ 74.031182] qcom-ethqos 23040000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> [ 74.031773] qcom-ethqos 23040000.ethernet eth0: Link is Down
>
> For reference, this board is using the same MAC as [0] which works
> perfectly fine with the AQR115C PHY. I got the (wrong) idea to add
> .get_rate_matching after comparing the two PHY drivers. The MAC driver
> is stmmac/dwmac-qcom-ethqos.c
>
> Ayaan
> ---
> [0] https://elixir.bootlin.com/linux/v6.17-rc5/source/arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts
Sorry, I missed adding the following.
After checking the phylink logs, I am now wondering if we need to
register a `.get_interfaces` callback in `dwmac-qcom-ethqos.c` and
do something like:
case PHY_INTERFACE_MODE_2500BASEX:
__set_bit(PHY_INTERFACE_MODE_2500BASEX, interfaces);
fallthrough;
case PHY_INTERFACE_MODE_SGMII:
__set_bit(PHY_INTERFACE_MODE_SGMII, interfaces);
break;
...
This is based on my limited understanding, so I’d love to hear your
thoughts.
Ayaan
> So, the bug is likely elsewhere, or your ethernet MAC doesn't support
> SGMII and you need to add complete support for rate-matching to the
> driver.
Russell beat me too it. Just adding:
static int qca808x_get_features(struct phy_device *phydev)
{
int ret;
ret = genphy_c45_pma_read_abilities(phydev);
if (ret)
return ret;
/* The autoneg ability is not existed in bit3 of MMD7.1,
* but it is supported by qca808x PHY, so we add it here
* manually.
*/
linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, phydev->supported);
/* As for the qca8081 1G version chip, the 2500baseT ability is also
* existed in the bit0 of MMD1.21, we need to remove it manually if
* it is the qca8081 1G chip according to the bit0 of MMD7.0x901d.
*/
if (qca808x_is_1g_only(phydev))
linkmode_clear_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, phydev->supported);
return 0;
}
So it appears this PHY breaks the standard in a number of ways. Maybe
it is broken in other ways which need additional workarounds.
Andrew
© 2016 - 2025 Red Hat, Inc.