OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Kernel
  • Assigned To
    Mathias Kresin
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by kestrel1974 - 04.01.2021
Last edited by Mathias Kresin - 29.03.2021

FS#3562 - no packet flow on AR 8035 based ports (LAN3, LAN4) of lantiq xrx200 integrated switch (with fix)

The device is fritzbox 7362sl.
It works until kernel 4.19.
The explicit calls to at803x_disable_rx_delay(phydev) and at803x_disable_tx_delay(phydev) seem to clobber the AR8035 registers 0 and 5 with values that make the two LAN ports not transporting anything anymore. Plugging and unplugging cables is still recognized.

I have used a small patch to revert the at803x_config_init function to how it was on kernel 4.19 and the two ports work since then:

 --- a/drivers/net/phy/at803x.c
 +++ b/drivers/net/phy/at803x.c
 @@ -289,20 +289,20 @@ static int at803x_config_init(struct phy_

  	if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 -	    phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
 +	    phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
  		ret = at803x_enable_rx_delay(phydev);
 -	else
 -		ret = at803x_disable_rx_delay(phydev);
 -	if (ret < 0)
 -		return ret;
 +		if (ret < 0)
 +			return ret;
 +	}

  	if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 -	    phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
 +	    phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
  		ret = at803x_enable_tx_delay(phydev);
 -	else
 -		ret = at803x_disable_tx_delay(phydev);
 +		if (ret < 0)
 +			return ret;
 +	}

 -	return ret;
 +	return 0;

  static int at803x_ack_interrupt(struct phy_device *phydev)

But, maybe the explicit call to at803x_disable_??_delay was added for some other device to work. I have experimented with pll-data first, but unlike newer kernels, like 5.10 this is nowhere referenced in the driver for the 5.4 kernel.

Actually, removing the disable calls and using just RGMII is effectivly similar to not touching the AT8035 registers 0 and 5 at all.

Closed by  Mathias Kresin
29.03.2021 19:07
Reason for closing:  Won't fix
Additional comments about closing:  

everything will be better with the gswip (DSA) driver

Project Manager
Mathias Kresin commented on 04.01.2021 21:16

Thanks a lot for your bug report and the analysis done.

at803x_enable_tx_delay()/at803x_disable_tx_delay() either set BIT 8 of the AT803X_DEBUG_REG_5 register to 1 or 0.

at803x_enable_rx_delay()/at803x_disable_rx_delay() either set BIT 15 of the AT803X_DEBUG_REG_0 register to 1 or 0.

Means, if the call to the disable functions breaks your network connectivity, your system rather needs a call to the enable functions to set the bits.

It only worked so far, since the correct values were present on boot and nothing removed (disabled) them till kernel 5.4.

Would you please test if the attached patch fixes your issue.

Project Manager
Mathias Kresin commented on 10.01.2021 20:47

I updated the attached patch. the first one was faulty.

kestrel1974 commented on 22.02.2021 14:26

Hi Mathias,

sorry for the delay, I just recognized your response when I got the notification in the forum.
However, with the patch there is no networking at all. Just the lo interface initializes.


Project Manager
Mathias Kresin commented on 22.02.2021 19:46

Would you please provide a bootlog. I'm curious why you have no network at all with the patch applied.

kestrel1974 commented on 24.02.2021 15:01

There are no messages in the bootlog at all for xrx200-net, Intel XWAY PHY11G or Atheros 8035 messages as they would be there without the patch. There is also no error message, just as initializing xrx200-net did not succeed or start to run.
Removing your patch makes it work again.

Project Manager
Mathias Kresin commented on 24.02.2021 20:54

It is strange. I tested the patch on a BT HomeHub 5a and I'm not able to see such an fallout.

Similar curious is, that your wireless seem to have an issue as well:

[    8.838531] ifx_pcie_wait_phy_link_up timeout
[    9.064161] ifx_pcie_wait_phy_link_up timeout
[    9.290225] ifx_pcie_wait_phy_link_up timeout
[    9.516112] ifx_pcie_wait_phy_link_up timeout
[    9.742178] ifx_pcie_wait_phy_link_up timeout
[    9.745108] pcie_rc_initialize link up failed!!!!!

If it only occurs when the patch is applied, there is no way I can associate it with the content of the patch.

However, the failing PCIe might prevent the successful load/initialization of the switch driver.

Would you mind to try to disable the PCIe temporary, by applying the following changes on top of 7362sl.patch:

--- a/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7362sl.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz7362sl.dts
@@ -76,6 +76,7 @@
 &pcie0 {
+       status = "disabled";
        gpio-reset = <&gpio 21 GPIO_ACTIVE_LOW>;
        pcie@0 {
kestrel1974 commented on 26.02.2021 06:52


The messages seem to be there after Kernel 4.14 or with Kernel 5.4. The bootlog in the wiki is 4.14.
The numbering for PCI and the initialization also differs from the AVM firmware (which is still kernel 3.10).
I have removed your patch and uploaded the bootlog and it shows the network devices.

Project Manager
Mathias Kresin commented on 26.02.2021 12:55
I have removed your patch and uploaded the bootlog and it shows the network devices.

But have you tried to apply 7362sl.patch and disabling PCIe as requested in my last comment?

kestrel1974 commented on 01.03.2021 13:46

yes, the PCIE messages are gone, but there is still no networking with the patch.

kestrel1974 commented on 01.03.2021 17:33

I wonder if PCIe is screwed up for some devices since kernel 4.14:

kestrel1974 commented on 29.03.2021 14:18

I am closing this, since the move to dsa gswitch is ahead and its not useful to spend time on the old driver.


Available keyboard shortcuts


Task Details

Task Editing