From: Florian Fainelli <f.fainelli@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
vivien.didelot@savoirfairelinux.com,
jerome.oufella@savoirfairelinux.com, linux@roeck-us.net,
cphealy@gmail.com, mathieu@codeaurora.org, jonasj76@gmail.com,
andrey.volkov@nexvision.fr, Chris.Packham@alliedtelesis.co.nz
Subject: Re: [RFC PATCH net-next 0/8] net: dsa: New registration API
Date: Thu, 30 Apr 2015 10:50:53 -0700 [thread overview]
Message-ID: <55426B7D.90207@gmail.com> (raw)
In-Reply-To: <20150430172726.GF18874@lunn.ch>
On 30/04/15 10:27, Andrew Lunn wrote:
> On Thu, Apr 30, 2015 at 09:50:36AM -0700, Florian Fainelli wrote:
>> On 30/04/15 06:12, Andrew Lunn wrote:
>>>> Note that there are currenlty no incompatibles changes made to existing Device
>>>> Tree sources, rather, depending on the bus we are probed for, e.g: MDIO
>>>> the dsa,mii-bus and dsa,ethernet phandles and first cell of the "reg" property
>>>> will become obsolete, everything else remains entirely compatible.
>>>
>>> Hi Florian
>>>
>>> I'm not sure dsa,mii-bus and dsa,ethernet will become obsolete. At
>>> least they are probably needed for multi switch setups, and the
>>> possible but probably unlikely multi DSA setups.
>>>
>>> You cannot assume that dsa,mii-bus and dsa,ethernet have the same
>>> parent. In a multi switch setup, it could be there is an mdio-mux in
>>> the picture. So all your probe really tells you, is that there is a
>>> switch on this mii bus, but you don't know what ethernet it is hanging
>>> off.
>>
>> Good point.
>>
>>>
>>> The switch could be hanging off multiple ethernets. I'm working on
>>> supporting this for the WRT1900AC, where i use the bond driver on the
>>> host side. So dsa,ethernet is a phandle to a bond interface.
>>
>> Humm, bond is a software constructs,
>
> I thought about this for a while, and came to the conclusion that it
> is often a software construct, but it can also be a hardware
> construct, when you have two ethernet interfaces connected to a
> switch, all on one PCB. So i added a DT binding for bonding. In the
> case of WRT1900AC, it looks like:
>
> bond: bond {
> compatible = "linux,bond";
> slaves = < ð0 >, < ð1 >;
> };
It seems to me that what we would want to represent here, is strictly
the two "CPU" MACs mapping to their respective ports of the switch
(assuming they are on different ports, right?).
Then whether they are part of a bond, such that you can utilize the full
Wi-Fi throughput, is left to the user to configure that.
For instance, on the Linksys EA4500 I use for prototyping, there are two
mv643xx_eth instances connected to a LAN-facing 4 ports group, and the
other to the WAN, port 5 of the switch, this is similar to Mathieu's use
case I believe, and whether we want to have a WAN/LAN separation, or
have the two MACs participate in a LAN or WAN bond should be
user-configurable.
By the same token, we could create bridges for ports 0-3 aka LAN
directly from Device Tree ;)
>
> and then in DSA i have a phandle to this bond interface. This part
> works great, but i've not posted these patches yet, because it does
> not work yet because of some other issue. Maybe when i do post this,
> it will get shot down?
I suppose you could post the patches and we look at this from there?
--
Florian
next prev parent reply other threads:[~2015-04-30 17:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 1:57 [RFC PATCH net-next 0/8] net: dsa: New registration API Florian Fainelli
2015-04-30 1:57 ` [RFC PATCH net-next 1/8] net: dsa: Move dsa_switch_tree final setup in separate function Florian Fainelli
2015-05-04 2:01 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 2/8] net: phy: Check fixup lists in get_phy_device() Florian Fainelli
2015-05-04 2:02 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 3/8] net: phy: Allow PHY devices to identify themselves as Ethernet switches Florian Fainelli
2015-04-30 12:56 ` Andrew Lunn
2015-04-30 16:39 ` Florian Fainelli
2015-04-30 17:16 ` Andrew Lunn
2015-04-30 17:37 ` Florian Fainelli
2015-04-30 17:48 ` Andrew Lunn
2015-04-30 18:04 ` Florian Fainelli
2015-04-30 18:19 ` Andrew Lunn
2015-04-30 1:57 ` [RFC PATCH net-next 4/8] net: mv643xx_eth: Handle Ethernet switches as PHY devices Florian Fainelli
2015-05-04 2:06 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 5/8] net: dsa: add new API to register switch devices Florian Fainelli
2015-05-04 2:09 ` David Miller
2015-04-30 1:57 ` [RFC PATCH net-next 6/8] net: dsa: bcm_sf2: make it a real platform driver Florian Fainelli
2015-04-30 1:57 ` [RFC PATCH net-next 7/8] net: dsa: mv88e6060: make it a proper PHY driver Florian Fainelli
2015-04-30 12:46 ` Andrew Lunn
2015-04-30 13:49 ` Guenter Roeck
2015-04-30 16:46 ` Florian Fainelli
2015-04-30 17:02 ` Andrew Lunn
2015-04-30 17:13 ` Florian Fainelli
2015-05-01 2:28 ` Guenter Roeck
2015-05-01 6:41 ` Florian Fainelli
2015-04-30 1:57 ` [RFC PATCH net-next 8/8] net: dsa: mv88e6xxx: Allow them to be proper PHY drivers Florian Fainelli
2015-04-30 13:12 ` [RFC PATCH net-next 0/8] net: dsa: New registration API Andrew Lunn
2015-04-30 16:50 ` Florian Fainelli
2015-04-30 17:27 ` Andrew Lunn
2015-04-30 17:50 ` Florian Fainelli [this message]
2015-04-30 18:14 ` Andrew Lunn
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=55426B7D.90207@gmail.com \
--to=f.fainelli@gmail.com \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=andrew@lunn.ch \
--cc=andrey.volkov@nexvision.fr \
--cc=cphealy@gmail.com \
--cc=davem@davemloft.net \
--cc=jerome.oufella@savoirfairelinux.com \
--cc=jonasj76@gmail.com \
--cc=linux@roeck-us.net \
--cc=mathieu@codeaurora.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.com \
/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).