Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1710631 > unrolled thread
| Started by | Vivek Unune <npcomplete13@gmail.com> |
|---|---|
| First post | 2017-08-14 06:50 +0200 |
| Last post | 2017-08-19 23:40 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500 Vivek Unune <npcomplete13@gmail.com> - 2017-08-14 06:50 +0200
Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500 Florian Fainelli <f.fainelli@gmail.com> - 2017-08-14 18:40 +0200
Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500 Vivek Unune <npcomplete13@gmail.com> - 2017-08-19 23:40 +0200
| From | Vivek Unune <npcomplete13@gmail.com> |
|---|---|
| Date | 2017-08-14 06:50 +0200 |
| Subject | Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500 |
| Message-ID | <uefu9-81s-1@gated-at.bofh.it> |
Florian,
On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune <npcomplete13@gmail.com> 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.
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
@@ -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;
+
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.
Thanks,
Vivek
[toc] | [next] | [standalone]
| From | Florian Fainelli <f.fainelli@gmail.com> |
|---|---|
| Date | 2017-08-14 18:40 +0200 |
| Message-ID | <ueqzg-6tX-19@gated-at.bofh.it> |
| In reply to | #1710631 |
On 08/13/2017 09:44 PM, Vivek Unune wrote:
> Florian,
>
> On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune <npcomplete13@gmail.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Vivek Unune <npcomplete13@gmail.com> |
|---|---|
| Date | 2017-08-19 23:40 +0200 |
| Message-ID | <ugjDk-6tm-21@gated-at.bofh.it> |
| In reply to | #1711198 |
On Mon, Aug 14, 2017 at 12:37 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> 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!
>
>>
>> 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_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.
This will be quite helpful as current implementation creates some confusion
when there are more than one cpu ports.
>
>>
>> @@ -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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web