[OpenWrt-Devel] [PATCH v2 0/2] Add support for ar8316.
Changes: v1 -> v2: * Fixed whitespace issues. * Added issue with port numbering to this email. --- These patches enhance the ar8216 driver with support for the ar8316 switch chip. Most changes are taken from the S16 driver in the TP-Link TLWR741ND sources, the AVM Fritz!Box 7390 sources, or directly read out values of the RouterStation Pro. The behaviour for ar8216 should be unaffected, but lacking a device with it I couldn't verify it. I made following changes: * Guarded any register accesses with a mutex to prevent a race condition on changing switch settings and flushing the ARL table. * Added a phy_id field with the Atheros phy id 1 to make sure that it only tries to access Atheros chips. * Added switch initialization for the RouterBoard 450G/750G and the Fritz!Box 7390. Only the first one is tested. * Enabled Jumbo frames for the switch. * Fixed a potential (small) memory leak in _config_init. Known issues: * PHY4 is hard coded as WAN port for the ar8316. * The mutex guards are probably too broad. This will be reduced by a later patch. * The full 4k entries VLAN table isn't usable. Currently it is limited to 128 entries. Setting it higher than ~2600 entries makes the ar8216_priv struct bigger than 8kB, surpassing the stack size and braking config_probe, the full 4k entries makes it bigger than 12kB and therefore bigger than kmalloc's max value. * Jumbo frames are always enabled on ar8316, but the cpu can't receive them since the ag71xx driver has no jumbo frame support. * The internal port numbers have nothing in common with the labels on the ports. * The port 1 isn't usable on the RouterStation Pro. Best Regards, Jonas Gorski Gorski (2): Add support for the ar8316 switch. ar71xx: Add the ar8316 driver to rs pro/rb-450g. .../base-files/etc/defconfig/rb-450g/network | 26 +++ .../etc/defconfig/routerstation-pro/network| 10 + target/linux/ar71xx/config-2.6.32 |1 + target/linux/ar71xx/config-2.6.33 |1 + target/linux/ar71xx/config-2.6.34 |1 + .../ar71xx/files/arch/mips/ar71xx/mach-rb4xx.c |1 + .../ar71xx/files/arch/mips/ar71xx/mach-ubnt.c |1 + .../generic-2.6/files/drivers/net/phy/ar8216.c | 231 .../generic-2.6/files/drivers/net/phy/ar8216.h | 22 ++ 9 files changed, 256 insertions(+), 38 deletions(-) create mode 100644 target/linux/ar71xx/base-files/etc/defconfig/rb-450g/network ___ 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
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.
Jonas Gorski írta: > 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): 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. The speed of the MDIO bus depends on the speed of the AHB bus. In theory it would be possible to decrease the speed of the AHB bus in the board init code, but that would affect the performance of the whole system. Another solution is to decrease the speed of the AHB bus before each MDIO bus access, and restore it after, but i don't know how it would affect other devices on the AHB bus. To be precise, there is yet another solution: configuring the AR8216 switch with special ethernet packets. > 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. 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. Regards, Gabor ___ 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, 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 wrote: > Jonas Gorski írta: >> On 6 April 2010 17:30, Gabor Juhos 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 > bootload
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
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
