Good day, Trying to debug the issue with eth0 link status flip-floping on my box I had dived a bit into ag71xx sources. In file ag71xx_ar7240.c which is driver for ar7240 built-in switch I suspect to found a minor bug (unrelated to my flip-flopping problem, but whatever). At line 528 in function ar7240sw_setup_port() variable dest_ports being set to calculated inverse mask for selected port. This value isn't being used for anything.
As for my problem with flip-flopping, I suspect it to be related to the "feature" provided in worker proc link_function() that polls the status of all ports every other HZ/2 and brings the eth0 netdev down in case there's no connection being detected on every switch port. I had hacked ag71xx_ar7240.c to use 100baseT instead of 1000baseT for CPU port and to always assume that there's link available on one of the ports (i.e. hardcoded "status" variable to be 1 in link_function()). Firmware with above changes was built successfully and flashed into dir-615-e4 box a couple hours ago. Now I'm monitoring its behavior. Obviously eth0 link software in-kernel status would be always "link detected" (and that's technically true for cpu port) due to my hack. The question is would it fix my problem with the loss of connectivity to the box through switch (LAN1-4) ports after a period of time under heavy traffic pressure. Settling up multiple iptraf threads testfarm a.t.m. Aside from that I've got general question about ethernet switches support in linux kernel. Looks like the only vanilla support I found is "Distributed Switch Architecture" a.k.a. DSA which at the first glance seems to target devices OpenWRT deals with: "...this driver supports are typically embedded in access points and routers..." (citation). Reading DSA description (and sources) farther it comes out that it is somehow limited in regard to exposing hardware vlan tagging capabilities. It turns out that with dsa hw switch is always configured to use isolated VLAN per port and exposes each switch port into userspace as a separate net device. Was this limitation the reason to implement new swconfig kernel/userspace API which seems to be OpenWRT-specific? My main intension asking about this dsa vs. swconfig thing is that I want to understand what are long-term perspectives for swconfig. Moving AR7240 built-in switch from dsa to swconfig brought in benefit of proper hardware vlan tagging support but also came with a price of functionality loss. DSA allows access to *MII of separate ports from userland allowing fine-grained control over transceivers (port speed, duplex mode, e.t.c.) with old-good mii-tool/ethtool. Current swconfig implementation don't allow it. After spending several hours reading sources it seems to me that it wouldn't be a hard task to brought this functionality back if swconfig API spec specify a way to access MII interface of individual port. Unfortunately I don't know if this assumption is right. Are there any examples out in the wild showing full-blown swconfig API implementation offering such kind of functionality? Are there swconfig API specs/docs available somewhere? I would try to implement this functionality for AR7240 switch in case somebody would be so kind to provide me with the aforementioned info. Thanks in advance. P.S. It seems to me that in proc dir_600_a1_setup() inside file mach-dir-600-a1.c there are two excess calls to ar71xx_init_mac() inside conditional branch which parses nvram for box mac address. It should be enough just to simply set "mac = mac_buff;" as "mac" is used later in ar71xx_init_mac() calls. -- Best regards, Alexey Loukianov mailto:mooro...@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
