Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
Hi, I hope you don't mind if I move the discussion back to openwrt-devel. Answering only you wasn't intentional; I changed my default now to reply all so it doesn't happen again. On 7 April 2010 17:12, Gabor Juhos juh...@openwrt.org wrote: Jonas Gorski írta: On 6 April 2010 17:30, Gabor Juhos juh...@openwrt.org wrote: Nah, it was not broken. The AR8216 driver was disabled by default because it is not usable on the AR913x based boards. The reason behind this is that you can't communicate with the switch via the MDIO bus, because its speed is too fast for the switch. I meant broken in the sense that the ag71xx driver ignored if the phy_device provided its own netif_rx/netif_receive_skb for packet mangling (as the ar8216 driver has). Ok. To be precise, there is yet another solution: configuring the AR8216 switch with special ethernet packets. I see. At least the WNR2000 v2's u-boot code seems to use the MDIO bus to configure the switch. The WRN2000 v2 is based on the AR7240. Okay, that explains it. But I also saw the special register read/write packet handling in some atheros' S26 uboot implementations. Yeah, it is available in several GPL tarballs. The automatic detection won't work with this switch due to the MDIO bus issue, so it won't be registered never. At the end, you can't use the netif_rx function of the phy device. If it doesn't get detected, this really is a non issue. Well, this is not true totally. I did try it on several boards, and it looks strange: That's the kind of feedback I had hoped for /before/ the patch got committed ;-) --- Planex MZK-W300NH: (Atheros AR9130 rev 1, CPU:400.000 MHz, AHB:200.000 MHz, DDR:400.000 MHz) 1st boot: 0x0005-0x007c : firmware ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth1: Atheros AG71xx at 0xba00, irq 5 Atheros AR71xx hardware watchdog driver version 0.1.0 2nd boot: 0x0005-0x007c : firmware ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth1: Atheros AG71xx at 0xba00, irq 5 Atheros AR71xx hardware watchdog driver version 0.1.0 3rd boot: 0x0005-0x007c : firmware ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth1: Atheros AG71xx at 0xba00, irq 5 ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] eth1: AR0 PHY driver attached. Atheros AR71xx hardware watchdog driver version 0.1.0 The ar8216 messages are ugly, and i bet that users will open tickets due to this. Okay, it seems it sometimes *does* work, and sometimes doesn't. Perhaps demoting the level to KERN_DEBUG would be better. --- TRENDnet TEW-632BRP: (Atheros AR9130 rev 1, CPU:400.000 MHz, AHB:100.000 MHz, DDR:400.000 MHz) 0x0003-0x003f : firmware ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth1: Atheros AG71xx at 0xba00, irq 5 eth1: AR8216 PHY driver attached. Atheros AR71xx hardware watchdog driver version 0.1.0 The switch is detected on the WAN interface at every boot. It is confusing a bit. Ethernet seems to be working, but the switch is not configurable via swconfig. Looking at the mach-tew-632brp.c, I guess the switch cpu port is attached to eth0, and eth1 is the WAN port. This is under the assumption it is usable like the ar8316. To prevent a false switch on the wan interface, the driver register itself as switch only if the phy address is 0. The problem probably here is that eth0 doesn't have a phy_mask, therefore the ag71xx never calls phy_connect() for it. Defining a phy_mask should fix it. And perhaps outputting whether the driver attached in switch mode or in simple phy mode would be helpful. --- Planex MZK-W04NU: (Atheros AR9132 rev 1, CPU:400.000 MHz, AHB:100.000 MHz, DDR:400.000 MHz) The AHB bus runs 200MHz originally on this device, but i have a patched bootloader. Additionaly, i have modified the phy mask for the ethernet interface. 0x0005-0x007c : firmware ag71xx_mdio: probed
Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
Hi Jonas, I hope you don't mind if I move the discussion back to openwrt-devel. Nope. Answering only you wasn't intentional; Heh, I did not notice that. I changed my default now to reply all so it doesn't happen again. :) ... The automatic detection won't work with this switch due to the MDIO bus issue, so it won't be registered never. At the end, you can't use the netif_rx function of the phy device. If it doesn't get detected, this really is a non issue. Well, this is not true totally. I did try it on several boards, and it looks strange: That's the kind of feedback I had hoped for /before/ the patch got committed ;-) Sorry, i did not have time earlier. Planex MZK-W300NH: (Atheros AR9130 rev 1, CPU:400.000 MHz, AHB:200.000 MHz, DDR:400.000 MHz) ... 3rd boot: 0x0005-0x007c : firmware ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth1: Atheros AG71xx at 0xba00, irq 5 ar8216: Unknown Atheros device [ver=16777215, rev=255, phy_id=004dd042] eth1: AR0 PHY driver attached. Atheros AR71xx hardware watchdog driver version 0.1.0 The ar8216 messages are ugly, and i bet that users will open tickets due to this. Okay, it seems it sometimes *does* work, and sometimes doesn't. Exactly. It is not reliable. Perhaps demoting the level to KERN_DEBUG would be better. That would be better, yes. Although it does not solve the issue completely. TRENDnet TEW-632BRP: (Atheros AR9130 rev 1, CPU:400.000 MHz, AHB:100.000 MHz, DDR:400.000 MHz) 0x0003-0x003f : firmware ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth1: Atheros AG71xx at 0xba00, irq 5 eth1: AR8216 PHY driver attached. Atheros AR71xx hardware watchdog driver version 0.1.0 The switch is detected on the WAN interface at every boot. It is confusing a bit. Ethernet seems to be working, but the switch is not configurable via swconfig. Looking at the mach-tew-632brp.c, I guess the switch cpu port is attached to eth0, and eth1 is the WAN port. That is right. This is under the assumption it is usable like the ar8316. To prevent a false switch on the wan interface, the driver register itself as switch only if the phy address is 0. The problem probably here is that eth0 doesn't have a phy_mask, therefore the ag71xx never calls phy_connect() for it. Defining a phy_mask should fix it. Yes, it does fix it. And perhaps outputting whether the driver attached in switch mode or in simple phy mode would be helpful. Yeah, that would be more informative. Planex MZK-W04NU: (Atheros AR9132 rev 1, CPU:400.000 MHz, AHB:100.000 MHz, DDR:400.000 MHz) The AHB bus runs 200MHz originally on this device, but i have a patched bootloader. Additionaly, i have modified the phy mask for the ethernet interface. 0x0005-0x007c : firmware ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4 eth0: AR8216 PHY driver attached. eth1: Atheros AG71xx at 0xba00, irq 5 eth1: AR8216 PHY driver attached. Atheros AR71xx hardware watchdog driver version 0.1.0 The switch is detected on both interfaces, and it is configurable with swconfig. But both LAN and WAN ports are stops working after i have configured the switch. Okay, in that case, you are probably bitten by the problem I described and wrote a patch for, Well, I have removed the 'has_ar8216' flag, so the ethernet driver does not adds/removes the header. And because the AR8216 driver is attached, it must use the mangle routine from that driver. although I am a bit stumped why the WAN port stopped working. I have no idea. I will do more testing later. Perhaps an easier workaround would be to unconditionally enable header mode for the ar8216, the special netif_receive_skb() handling wouldn't be needed anymore. Do you mean the special handling in the ag71xx driver itself? Although this would disable the invalid VID fixup. I also just saw that all 3 devices having 'has_ar8216' do not have a phy_mask defined, so the driver never has a chance to attach anyway. Incorrect, see above. You are right, they still have for the WAN port where it attaches itself. Yes, i have missed this fact earlier. Looking at the TEW-632BRP, I assume its bootloader doesn't enable the header mode? It doesn't have the 'has_ar8216' flag set. You are right, it is working in 'normal' mode. The AHB bus is running at 100MHz on that board. Can you check with the attached patch if it helps the Planex MZK-W04NU? Sure. Regards, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
Hi Gabor, Sorry, i did not have time earlier. No harm done (except for few devices ;-). Perhaps an easier workaround would be to unconditionally enable header mode for the ar8216, the special netif_receive_skb() handling wouldn't be needed anymore. Do you mean the special handling in the ag71xx driver itself? Although this would disable the invalid VID fixup. I also just saw that all 3 devices having 'has_ar8216' do not have a phy_mask defined, so the driver never has a chance to attach anyway. Incorrect, see above. You are right, they still have for the WAN port where it attaches itself. Yes, i have missed this fact earlier. Looking at the TEW-632BRP, I assume its bootloader doesn't enable the header mode? It doesn't have the 'has_ar8216' flag set. I just looked at the code again, and I think I know now how to fix the problem for the devices where the AR8216 is usable through MDIO. The problem is that the ag71xx driver should call the phy's netif_receive_skb, but it doesn't. I'll send a patch shortly. After that all devices where the AR8216 driver attaches successfully do not need their has_ar8216 flag anymore, as then the phy driver itself can handle it. The problems with the ar8216 driver itself will be adressed in a separate patch. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
Hi, *sigh* shortly after it got committed to trunk, I think I see how I broke ar8216 on ar71xx (actually it was already broken before): The header mode gets handled by the ar8216 driver itself, in theory, but the ar8216_netif_rx never gets called by the ag71xx driver. This leads to following situations: Header mode is disabled (= no VLANs): rx: ag71xx tries to remove header, fails = no rx tx: ag71xx adds header = packet gets dropped by switch Header mode is enabled: rx: ag71xx tries to remove header, succeeds = ok tx: ar8216 driver adds header, ag71xx adds header = packet gets dropped I'll take a look at where the ag71xx should call the phy's netif_rx(), this should make the special ar8216 support obselete in general. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
Hi, any comments on these patches? It would be really nice if these made it into backfire, as they not only make vlan configuration possible, but also solve a multicast problem for the Routerstation Pro (and probably the RB450G/750G). Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
On 05-04-10 12:44, Jonas Gorski wrote: Hi, Hi Jonas, any comments on these patches? It would be really nice if these made it into backfire, as they not only make vlan configuration possible, but also solve a multicast problem for the Routerstation Pro (and probably the RB450G/750G). I've been using your patches on my main RSPro at home since you've sent them to this list, and I haven't ran into problems until now. Thanks again for your work on this. As I've mentioned in my reply to your previous patchset, I've tested combinations of multiple tagged vlan's on the first two ports and a single untagged vlan on the third port. Since they also enable multicast on the port connected to eth1, they allow me to use programs like igmpproxy, OSPF, or UPnP. Without your patches, the Routerstation Pro is almost useless, so I totally agree with you that it would be nice to have them in Backfire. Especially since several people on IRC seem to be using at least one of these boards, and well, the patches are here and they work. Since I don't own a normal Routerstation, I'm unable to test if this breaks ar8216, but I cant imagine that nobody who owns one wants to quickly test this. So I ask again if someone could do so, pretty please :-) Worst case scenario I order an RS myself and let you know how it turns out. It's pretty cheap, and I have to order some stuff from my supplier anyway. But then I'm sponsoring Ubiquiti again, which is something I've already regretted doing, because of their ridiculous idea of support. Especially since their SDK just seems to be a copy of OpenWrt with some changes and additions... Regards, Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
On 04/05/2010 07:50 PM, Stijn Tintel wrote: Since I don't own a normal Routerstation, I'm unable to test if this breaks ar8216, but I cant imagine that nobody who owns one wants to quickly test this. So I ask again if someone could do so, pretty please :-) Worst case scenario I order an RS myself and let you know how it turns out. It's pretty cheap, and I have to order some stuff from my supplier anyway. Be careful, according to http://www.ubnt.com/wiki/index.php?title=RouterStation a Routerstation features an ADM6996FC, not an AR8216 switch. There aren't that many devices with the AR8216 out there. /Jörg ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
