netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Olivari <mathieu@codeaurora.org>
To: netdev@vger.kernel.org
Cc: linux@roeck-us.net, andrew@lunn.ch, jogo@openwrt.org,
	f.fainelli@gmail.com
Subject: RFC: dsa: add support for multiple CPU ports
Date: Tue, 10 Mar 2015 12:01:29 -0700	[thread overview]
Message-ID: <20150310190129.GB5636@codeaurora.org> (raw)

Hi all,

I’m writing a DSA driver for some QCA network switches already supported in
OpenWrt using swconfig. They connect to the CPU using MDIO for configuration,
and xMII ports for data. The main difference with what is supported comes from
the fact that most of these switches actually have multiple xMII connections to
the same CPU. Something like this:
(extending the picture from http://lwn.net/Articles/302333/)

	+-----------+       +-----------+
	|           | RGMII |           |
	|       eth0+-------+           +------ 1000baseT MDI ("WAN")
	|        wan|       |  7-port   +------ 1000baseT MDI ("LAN1")
	|   CPU     |       |  ethernet +------ 1000baseT MDI ("LAN2")
	|           | RGMII |  switch   +------ 1000baseT MDI ("LAN3")
	|       eth1+-------+  w/5 PHYs +------ 1000baseT MDI ("LAN4")
	|        lan|       |           |
	+-----------+       +-----------+
	          |   MDIO     |
	          \------------/

In a typical configuration, we configure the switch to isolate WAN & LAN from
each other.

The current DSA implementation is based on the assumption that there can be only
one xMII connection between the switch and the CPU (this switch port is known as
the CPU port), which obviously doesn't work anymore in that case. So I'm trying
to figure out the best way to extend DSA to support these hardware.

Here is my proposal. I was hoping to get feedback before i get too much down the
implementation path:
*add an optional phandle (cpu_dev) to the existing port device node, which would
 reference the ethernet device node this port is connected to
*save the corresponding net_device in the "ports" field of "struct dsa_switch"
*instrument the network layer to be able to look-up which switch port is
 connected to a particular net_device.

The third point would allow to perform operations currently limited to switch
ports. Typically, "ethtool -S eth0" could return the corresponding port's MIB
statistics in addition to the eth0 statistics.

Thoughts?

Thanks,
Mathieu

             reply	other threads:[~2015-03-10 19:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 19:01 Mathieu Olivari [this message]
2015-03-10 19:21 ` RFC: dsa: add support for multiple CPU ports Andrew Lunn
2015-03-10 22:13   ` Mathieu Olivari
2015-03-10 22:50     ` Andrew Lunn
2015-03-10 19:31 ` Andrew Lunn
2015-03-10 20:42   ` Mathieu Olivari
2015-03-10 21:13     ` Andrew Lunn
2015-03-10 22:53       ` Mathieu Olivari
2015-03-11  1:47         ` David Miller
2015-03-11 13:07       ` Jiri Pirko
2015-03-11  0:01     ` Florian Fainelli
2015-03-11  1:18       ` Mathieu Olivari
2015-03-11 13:30         ` Andrew Lunn
2015-03-11 23:37           ` Mathieu Olivari
2015-03-12  0:19             ` Andrew Lunn
2015-03-13  1:57               ` Mathieu Olivari

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=20150310190129.GB5636@codeaurora.org \
    --to=mathieu@codeaurora.org \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=jogo@openwrt.org \
    --cc=linux@roeck-us.net \
    --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).