New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#3562 - no packet flow on AR 8035 based ports (LAN3, LAN4) of lantiq xrx200 integrated switch (with fix) #8729
Comments
mkresin: 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. |
mkresin: I updated the attached patch. the first one was faulty. |
kestrel1974: Hi Mathias, sorry for the delay, I just recognized your response when I got the notification in the forum. Thanks. |
mkresin: Would you please provide a bootlog. I'm curious why you have no network at all with the patch applied. |
kestrel1974: 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. |
mkresin: 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 @@
};
|
kestrel1974: Hi, The messages seem to be there after Kernel 4.14 or with Kernel 5.4. The bootlog in the wiki is 4.14. |
mkresin:
But have you tried to apply 7362sl.patch and disabling PCIe as requested in my last comment? |
kestrel1974: yes, the PCIE messages are gone, but there is still no networking with the patch. |
kestrel1974: I wonder if PCIe is screwed up for some devices since kernel 4.14: |
kestrel1974: I am closing this, since the move to dsa gswitch is ahead and its not useful to spend time on the old driver. |
kestrel1974:
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_ */
-
-
- else
-
- if (ret < 0)
-
-
-
-
-
-
- else
-
-
-
- }
- return ret;
- return 0;
}
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
}
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.
The text was updated successfully, but these errors were encountered: