Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500
From: Vivek Unune <hidden>
Date: 2017-08-19 21:30:29
Also in:
linux-arm-kernel, lkml
On Mon, Aug 14, 2017 at 12:37 PM, Florian Fainelli [off-list ref] wrote:
quoted
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.
It appears that I do not need to set any phy-mode on internal sw's port 0 or external sw's port 8. Also, you were right about internal port 0 to be configured as tagged member of the vlan. It was indeed set to untagged! LEDE lacks aw way to configure this. But I can do this via a post script. After making above changes I was able to ping the router using physical port on external switch. However, the ping dies out after few seconds. I'm try to figure out the cause for this. Al least, I have some connectivity!
quoted
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 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_25I 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.
This will be quite helpful as current implementation creates some confusion when there are more than one cpu ports.
quoted
@@ -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.
I tried to remove setting of SM_SW_FWD_MODE but no go. Even GPL source sets it for 53012. For now I'll leave it until I get back to it.
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
Thanks for your time!! Vivek