[OpenWrt-Devel] [PATCH] ar71xx: fix kernel Oops in at803x_link_change_notify

Sven Eckelmann sven at open-mesh.com
Fri Jul 3 06:29:32 EDT 2015

On Wednesday 01 July 2015 16:34:07 Christian Lamparter wrote:
> On Tuesday, June 30, 2015 05:35:12 PM Sven Eckelmann wrote:
> > r45954 ("ar71xx: fix 100/10mbps ethernet link issues on mynet range
> > extender") introduced a pdata based modification of the tx_clk_dly. But it
> > was not checked if pdata actually existed. This caused a page fault on all
> > devices which didn't have at803x_platform_data specified for an at803x
> > based device.
> > 
> Ah finally. I tried to contact you several times before. 
> (RFC back in May)

Yes, missed the Cc mail "[RFT/RFC] ar71xx: fix 100/10mbps ethernet link issues
on mynet range extender" and "Re: [OpenWrt-Devel] [PATCH] ar71xx: fix
100/10mbps ethernet link issues on mynet range extender". Sorry about that -
it is my fault because I have not yet figured out how to force google to
handle Cc'ed/To'ed/Bcc'ed mails special and not to put them in my "Mailing
List - read a lot later" folder just because the original thread is in this
folder. Marek gave me a list of workarounds which I promise to try out.

> Sven, I've seen you did quite a bit of work on the OM5P-AN
> with the same F1E-PHY. I went through the code from Atheros'
> original driver SDK v17 (which was part of the GPL source
> for the mynet). Apart from tx delay handling, everything
> else matches perfectly, so the tx/rx delay code should be
> enabled by default for this chip on all platforms without
> needing any platform data overwrites.

Interesting, I don't have the SDK and I am only using OpenWrt. So I cannot say
anything about the Atheros driver. But sounds like you are right. At least all
recent devices I had in my hand required this change.

I also saw your fixup_rgmii_tx_delay delay change. I would ack when you submit
a change like this. Just don't forget that the pll_1000 has also to be changed
(especially when you move the default values to at803x.c):

--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c
@@ -154,7 +154,8 @@ static struct i2c_board_info om5pan_i2c_devs[] __initdata = {
 static struct at803x_platform_data om5p_an_at803x_data = {
 	.disable_smarteee = 1,
 	.enable_rgmii_rx_delay = 1,
-	.enable_rgmii_tx_delay = 1,
+	.enable_rgmii_tx_delay = 0,
+	.fixup_rgmii_tx_delay = 1,
 static struct mdio_board_info om5p_an_mdio0_info[] = {
@@ -201,7 +202,7 @@ static void __init om5p_an_setup(void)
 	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
 	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
 	ath79_eth0_data.phy_mask = BIT(7);
-	ath79_eth0_pll_data.pll_1000 = 0x02000000;
+	ath79_eth0_pll_data.pll_1000 = 0x0e000000;
 	ath79_eth0_pll_data.pll_100 = 0x00000101;
 	ath79_eth0_pll_data.pll_10 = 0x00001313;

I don't have the equipment to check the actual signals (as you said in an
earlier mail) - only some people which complained very loud when their long
cable setup didn't work. :)

Maybe there are some non atheros SoC's out there which would have problems
when you would change the default behavior of the AT8035.

> I'm interested to hear from any other devices which have 
> a AT803x. Also, please let me know where to get the GPL
> tars for the devices.

I have forwarded your mail to the person which is handling the actual
firmware builds of the OM5P-AN. He will contact you later and provide
the sources.

Kind regards,
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list