Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752655AbdHNQhb (ORCPT ); Mon, 14 Aug 2017 12:37:31 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:34314 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbdHNQh2 (ORCPT ); Mon, 14 Aug 2017 12:37:28 -0400 Subject: Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500 To: Vivek Unune , Florian Fainelli Cc: Andrew Lunn , hauke@hauke-m.de, zajec5@gmail.com, bcm-kernel-feedback-list@broadcom.com, robh+dt@kernel.org, mark.rutland@arm.com, linux@armlinux.org.uk, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <1489590033-4946-1-git-send-email-npcomplete13@gmail.com> <20170315185214.GF21021@lunn.ch> <7f5ddeba-6f79-9de5-2c67-a77e6bec0ef9@broadcom.com> <2e4ed52f-4134-9b6a-18c9-7c1f28cd7038@broadcom.com> <03ba6198-a2cc-da9f-7d7d-f626d53d5717@gmail.com> From: Florian Fainelli Message-ID: Date: Mon, 14 Aug 2017 09:37:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 10278 Lines: 312 On 08/13/2017 09:44 PM, Vivek Unune wrote: > Florian, > > On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune wrote: >> Florian, >> >>>> I have managed to use DSA driver and was able detect both internal and >>>> external switches. However, I only get packets flowing only through the >>>> internal switch. I have used the ip & bridge commands to setup the vlan >>>> 101 & 102 for lan and wan respectively. >>>> >>>> VLAN101 = lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8 eth0.101 >>> >>> That looks reasonable although keep in mind that the IMP/CPU interfaces >>> of the switch are configured with VLAN tags (see commit [1]), so you may >>> need to make sure that port 0 of the internal switch is not accidentally >>> configured back to untagged since that would cause problem when >>> terminating the VLAN tag on the SW side. >>> >>> So here are a few things that you want to check: >>> >>> - read the MIB counters from the "extswitch" interface and see if >>> packets flow through in both directions with no errors >> >> lan4 is on internal switch, lan1 on external. I cannot ping router from lan1 >> >> Inter- | Receive | Transmit >> face |bytes packets errs drop|bytes packets errs drop >> br-lan: 168590 1726 0 0 190542 753 0 0 >> extswitch: 0 0 0 0 101012 1221 0 0 >> lan1: 0 0 0 0 5382 111 0 0 >> lan4: 0 0 0 0 1306680 13909 0 0 >> eth0: 3276924 5539 0 0 1106135 5084 0 0 >> eth0.101: 169338 1732 0 0 190256 750 0 0 >> eth0.102: 2959522 3274 0 0 587248 1094 0 0 >> lo: 39390 502 0 0 39390 502 0 0 >> br-wan: 2956822 3254 0 0 587248 1094 0 0 >> > > Please ignore above mib counters. I noticed that I see lot of RxFCSErrors > and RxSymbolErrors for extswitch. The count for both counters always > remain same. Yes that is not exactly good, it means that the RGMII interface between the internal and external switches is not properly configured. > > root@LEDE:/# ethtool -S extswitch > NIC statistics: > tx_packets: 212 > tx_bytes: 19179 > rx_packets: 0 > rx_bytes: 0 > TxOctets: 14403 > TxDropPkts: 0 > TxBroadcastPkts: 24 > TxMulticastPkts: 122 > TxUnicastPkts: 0 > TxCollisions: 0 > TxSingleCollision: 0 > TxMultipleCollision: 0 > TxDeferredTransmit: 0 > TxLateCollision: 0 > TxExcessiveCollision: 0 > TxPausePkts: 0 > RxOctets: 3593 > RxUndersizePkts: 0 > RxPausePkts: 0 > Pkts64Octets: 0 > Pkts65to127Octets: 36 > Pkts128to255Octets: 1 > Pkts256to511Octets: 0 > Pkts512to1023Octets: 0 > Pkts1024to1522Octets: 0 > RxOversizePkts: 0 > RxJabbers: 0 > RxAlignmentErrors: 0 > RxFCSErrors: 37 > RxGoodOctets: 0 > RxDropPkts: 0 > RxUnicastPkts: 0 > RxMulticastPkts: 0 > RxBroadcastPkts: 0 > RxSAChanges: 0 > RxFragments: 0 > RxJumboPkts: 0 > RxSymbolErrors: 37 > RxDiscarded: 0 > p08_TxOctets: 47537 > p08_TxDropPkts: 0 > p08_TxBroadcastPkts: 163 > p08_TxMulticastPkts: 319 > p08_TxUnicastPkts: 0 > p08_TxCollisions: 0 > p08_TxSingleCollision: 0 > p08_TxMultipleCollision: 0 > p08_TxDeferredTransmit: 0 > p08_TxLateCollision: 0 > p08_TxExcessiveCollision: 0 > p08_TxPausePkts: 0 > p08_RxOctets: 14403 > p08_RxUndersizePkts: 0 > p08_RxPausePkts: 0 > p08_Pkts64Octets: 25 > p08_Pkts65to127Octets: 102 > p08_Pkts128to255Octets: 17 > p08_Pkts256to511Octets: 2 > p08_Pkts512to1023Octets: 0 > p08_Pkts1024to1522Octets: 0 > p08_RxOversizePkts: 0 > p08_RxJabbers: 0 > p08_RxAlignmentErrors: 0 > p08_RxFCSErrors: 0 > p08_RxGoodOctets: 14403 > p08_RxDropPkts: 0 > p08_RxUnicastPkts: 0 > p08_RxMulticastPkts: 122 > p08_RxBroadcastPkts: 24 > p08_RxSAChanges: 40 > p08_RxFragments: 0 > p08_RxJumboPkts: 0 > p08_RxSymbolErrors: 0 > p08_RxDiscarded: 146 > > >>> >>> - check the "extswitch" VLAN configuration on both the internal switch >>> side (port 0) and on the external switch side ("cpu", port 8, not visible) >> >> #bridge vlan show >> port vlan ids >> extswitch None >> extswitch >> lan7 101 PVID Egress Untagged >> lan7 101 PVID Egress Untagged >> lan4 101 PVID Egress Untagged >> lan4 101 PVID Egress Untagged >> lan8 101 PVID Egress Untagged >> lan8 101 PVID Egress Untagged >> wan 102 PVID Egress Untagged >> wan 102 PVID Egress Untagged >> lan1 101 PVID Egress Untagged >> lan1 101 PVID Egress Untagged >> lan5 101 PVID Egress Untagged >> lan5 101 PVID Egress Untagged >> lan2 101 PVID Egress Untagged >> lan2 101 PVID Egress Untagged >> lan6 101 PVID Egress Untagged >> lan6 101 PVID Egress Untagged >> lan3 101 PVID Egress Untagged >> lan3 101 PVID Egress Untagged >> br-lan None >> eth0.101 101 PVID Egress Untagged >> eth0.101 >> br-wan None >> eth0.102 102 PVID Egress Untagged >> eth0.102 >> >>> >>> - see if you can get traffic end-to-end from eth0 all the way through >>> one of the external switch port. If that's the case, that means that the >>> configuration of internal switch port 0, internal switch CPU port, and >>> external switch external port is working and operational >>> >>> [1]: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e47112d9d6009bf6b7438cedc0270316d6b0370d >>> >>>> VLAN102 = wan eth0.102 >>>> >>>> Reading configs from the factory firmware, I'm sure that sw0port0 and> sw1port8 are connected. Excerpt from the same: >>>> >>>> port_numbers=0 2 4 2 1 3 1 3 >>>> port_switch_id=1 1 1 0 1 1 0 0 >>>> port_names=port0 port1 port2 port3 port4 port5 port6 port7 >>> >>> Is 0 the identifier for the external or internal switch? If 0 is >>> internal switch identifier and 1 is the external switch identifier, your >>> mapping looks correct to me with one exception below: >> >> 0 is internal here. >> >>> >>>> cpu_port_number=5 7 8 >>>> cpu_port_switch_id=0 0 0 >>>> hidden_port_numbers=0 8 >>>> hidden_port_switch_id=0 1 >>>> >>>> Below is my updated device tree. >>>> >>>> Thanks, >>>> >>>> Vivek >>>> >>>> &srab { >>>> compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab"; >>>> status = "okay"; >>>> dsa,member = <0 0>; >>>> >>>> ports { >>>> #address-cells = <1>; >>>> #size-cells = <0>; >>>> >>>> port@1 { >>>> reg = <1>; >>>> label = "lan7"; >>>> }; >>>> >>>> port@2 { >>>> reg = <2>; >>>> label = "lan4"; >>>> }; >>>> >>>> port@3 { >>>> reg = <3>; >>>> label = "lan8"; >>>> }; >>>> >>>> port@4 { >>>> reg = <4>; >>>> label = "wan"; >>>> }; >>>> >>>> port@5 { >>>> reg = <5>; >>>> ethernet = <&gmac0>; >>>> label = "cpu"; >>>> >>>> fixed-link { >>>> >>>> speed = <1000>; >>>> full-duplex; >>>> }; >>>> }; >>> >>> I think this is meant to be port 8 here based on the hidden_port_number >>> value. This actually matters for VLAN configuration because B53 is not >>> (unfortunately, to be fixed) consistently using dst->cpu_port (whatever >>> is configured in Device Tree) vs. dev->cpu_port (hardcoded to 8 for this >>> class of switch). >> >> When I connect to port 8 I receive no packets on internal switch. > > I'm able to now use sw0port8 <-> eth2 (i.e use cpu port 8 to connect to gmac2). > For this I had to modify net/dsa/b53/b53_common.c (see below). This is how > it is setup in net/phy/b53/b53_common.c. Also need to set > cpu_port = B53_CPU_PORT for 53012 sw instead of B53_CPU_PORT_25 I actually plan to remove the use cpu_port entirely, or actually only use it as a "hint" of which CPU ports are capable of supporting Broadcom tags. A better change for now would be not to use dev->cpu_port, but instead use ds->dst->cpu_dp->index like what b53_br_join() does. > > @@ -357,9 +357,11 @@ static void b53_enable_vlan(struct b53_d > b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL5, &vc5); > } > > - mgmt &= ~SM_SW_FWD_MODE; > > if (enable) { > + > + mgmt |= SM_SW_FWD_MODE; > + Humm, that I don't really understand because this is turning on managed mode which only influences how multicast addresses are processed, it should not make a different for non-MC traffic AFAICT. > vc0 |= VC0_VLAN_EN | VC0_VID_CHK_EN | VC0_VID_HASH_VID; > vc1 |= VC1_RX_MCST_UNTAG_EN | VC1_RX_MCST_FWD_EN; > vc4 &= ~VC4_ING_VID_CHECK_MASK; > >> >>> >>> PS: on that front, we will have to rework that when we bring multiple >>> CPU port support in DSA/B53/bcm_sf2 and so for now what we could do is >>> just check that the configured CPU port in Device Tree is a valid CPU >>> port for that switch (typically 5, 7 or 8), and if not, just issue a >>> warning. >>> >>>> >>>> sw0port0: port@0 { >>>> reg = <0>; >>>> label = "extswitch"; >>>> >>>> fixed-link { >>>> speed = <1000>; >>>> full-duplex; >>>> }; >>> >>> There might be some additional configuration needed here for this port, >>> because by default, the port will most likely try to use its built-in >>> PHY and maybe that's what they did, they wired the built-in PHY directly >>> to the IMP port of the external switch. >> >> Do you know what that configuration might be? > > Given that I see RxFCSErrors and RxSymbolErrors errors wrt extswitch. > configuration definitely needs tweaking. I tried setting the phy-mode to > rgmii and rgmii-txid but no go. Configuration may have to be tuned on both switches unfortunately because both RGMII interfaces would have the ability to configure delays. Do you have a way to dump what the original firmware settings for the register that b53_adjust_link() modifies such that we can see what was previous configured? Thanks! -- Florian