From: John Crispin <john@phrozen.org>
To: Andrew Lunn <andrew@lunn.ch>, Florian Fainelli <f.fainelli@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: dsa: handling more than 1 cpu port
Date: Wed, 14 Dec 2016 11:01:54 +0100 [thread overview]
Message-ID: <1671ae82-c213-7611-584f-02a3b1d5dff9@phrozen.org> (raw)
Hi Andrew,
switches supported by qca8k have 2 gmacs that we can wire an external
mii interface to. Usually this is used to wire 2 of the SoCs MACs to the
switch. Thw switch itself is aware of one of the MACs being the cpu port
and expects this to be port/mac0. Using the other will break the
hardware offloading features. The original series from Matthieu added a
feature to configure the switch in a pass-through mode [1]. This
resulted in us having to define the pass-through inside the dts which
means that we loose userland configurability. Assume the setup as
follows ...
port0 - cpu port wired to SoCs MAC0
port1-4 - the lan ports
port5 - the wan port
port6 - wired to the SoCs MAC1
What i have done now is bring up one bridge for port1-4 and a second one
for port5-6. Once setup I can pass traffic on the SoCs MAC1 and it will
flow via port6 and egress on port5. So far so good, however due to the
way the port based vlans are setup and how the bridge_join/leave() logic
works, port5/6 will also fwd traffic to the cpu port. the driver has now
to tell that we are trunking traffic on eth1 via port6. also the MII
mode is not known to the driver. Adding some hackish register writes
will make this work nicely. My proposed way of fixing this cleanly in an
upstream friendly way would be as follows
1) add an extra dsa,ethernet property to the 2nd MII port
dsa@0 {
compatible = "qca,ar8xxx";
dsa,ethernet = <&gmac1>;
[...]
switch@0 {
[...]
port@5 {
reg = <5>;
label = "wan";
phy-handle = <&phy_port5>;
};
port@6 {
reg = <6>;
label = "gmac2";
dsa,ethernet = <&gmac2>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
2) fix up the port_bridge_join/leave() logic such that if a port is
present in the bridge that has a reference to a ethernet interface it
will remove all ports in the bridge from the port based vlan of the
actual cpu port.
3) in case of this switch we also need to fiddle with the bcast/mcast
flooding registers
would this be ok and would it be better to probe the extra dsa_ethernet
inside the subsystem or the driver ? i was considering to do add a
dsa_is_trunk_port() or similar to achieve this.
John
[1] https://patchwork.ozlabs.org/patch/477525/
next reply other threads:[~2016-12-14 10:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 10:01 John Crispin [this message]
2016-12-14 10:31 ` dsa: handling more than 1 cpu port Andrew Lunn
2016-12-14 10:35 ` John Crispin
2016-12-14 11:00 ` Andrew Lunn
2016-12-14 11:11 ` John Crispin
2016-12-14 15:45 ` John Crispin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1671ae82-c213-7611-584f-02a3b1d5dff9@phrozen.org \
--to=john@phrozen.org \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).