netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: xiaofeis@codeaurora.org
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Niklas Cassel <niklas.cassel@linaro.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] net: dsa: read mac address from DT for slave device
Date: Wed, 27 Feb 2019 10:04:06 +0800	[thread overview]
Message-ID: <9962d7a13bb25c88cc42b3f4dd68cee7@codeaurora.org> (raw)
In-Reply-To: <967ec7b53270f1e29bb25e087c1a67a4@codeaurora.org>

On 2019-02-26 15:45, xiaofeis@codeaurora.org wrote:
> On 2019-02-26 01:27, Florian Fainelli wrote:
>> On 2/25/19 5:28 AM, xiaofeis@codeaurora.org wrote:
>>> Hi Florian
>>> 
>>> We have two slave DSA interfaces, wan0 and lan0, one is for wan port,
>>> and the other is for lan port. Customer has it's mac address pool, 
>>> they
>>> want
>>> to assign the mac address from the pool on wan0, lan0, and other
>>> interfaces like
>>> wifi, bt. Coreboot/uboot will populate it to the DTS node, so the 
>>> driver
>>> can
>>> get it from it's node. For DSA slave interface, it already has it's 
>>> own
>>> DTS node, it's
>>> easy to just add one porperty "local-mac-address" there for the usage 
>>> in
>>> DSA driver.
>>> 
>>> If not use DSA framework, normally we will use eth0.x and eth0.y for 
>>> wan
>>> and lan.
>>> On this case, customer usually also assign the MAC address on these
>>> logical interface
>>> from it's pool.
>> 
>> OK, but this is not necessary per my previous explanation: the CPU <=>
>> WAN pipe is a separate broadcast domain (otherwise it is a security 
>> hole
>> since you exposing LAN machines to the outside world), and so there is
>> no need for a separate MAC address. It might be convenient to have 
>> one,
>> especially for the provider, if they run a management software (e.g.:
>> TR69), but it is not required per-se.
>> 
>> Let me ask a secondary question here, how many Ethernet MACs connect 
>> to
>> the switch in this configuration? Is there one that is supposed to be
>> assigned all LAN traffic and one that is supposed to be assigned all 
>> WAN
>> traffic? If so, then what you are doing makes even less
>> 
> 
> Only one MAC connected to switch cpu port, both lan0 and wan0 are on 
> the top of
> same interface(eth0).
> 
Customer doesn't care about the MAC controller's MAC address, just leave 
it as the driver
randomly generated. They just want to assign the MAC address on wan and 
lan DSA logical
interface.

Many customer doesn't use DSA, for example, they use eth0.1/eth0.2 for 
lan/wan with one MAC controller.
They configure switch wan port in vlan2 group, and lan port in vlan1 
group, they usually assign mac address
on the logical interface(eth0.1&eth0.2), i think this is similar with 
DSA slave interfaces.

>>> 
>>> On 2019-02-22 23:43, Florian Fainelli wrote:
>>>> On 2/22/19 4:58 AM, Vinod Koul wrote:
>>>>> From: Xiaofei Shen <xiaofeis@codeaurora.org>
>>>>> 
>>>>> Before creating a slave netdevice, get the mac address from DTS and
>>>>> apply in case it is valid.
>>>> 
>>>> Can you explain your use case in details?
>>>> 
>>>> Assigning a MAC address to a network device that represents a switch
>>>> port does not quite make sense in general. The switch port is really
>>>> representing one end of a pipe, so one side you have stations and on 
>>>> the
>>>> other side, you have the CPU/management Ethernet MAC controller's 
>>>> MAC
>>>> address which constitutes a station as well. The DSA slave network
>>>> devices are just software constructs meant to steer traffic towards
>>>> specific ports of the switch, but they are all from the perpsective 
>>>> of
>>>> traffic reaching the CPU Port in the first place, therefore traffic 
>>>> that
>>>> is generally a known unicast Ethernet frame with the CPU's MAC 
>>>> address
>>>> as MAC DA (and of course all types of unknown MC, management traffic
>>>> etc.)
>>>> 
>>>> By default, DSA switch need to come up in a configuration where all
>>>> ports (except CPU/management) must be strictly separate from every 
>>>> other
>>>> port such that we can achieve what a standalone Ethernet NIC would 
>>>> do.
>>>> This works because all ports are isolated from one another, so there 
>>>> is
>>>> no cross talk and so having the same MAC address (the one from the 
>>>> CPU)
>>>> on the DSA slave network devices just works, each port is a separate
>>>> broadcast domain.
>>>> 
>>>> Once you start bridging one or ore ports, the bridge root port will 
>>>> have
>>>> a MAC address, most likely the one the CPU/management Ethernet MAC, 
>>>> but
>>>> similarly, this is not an issue and that's exactly how a software 
>>>> bridge
>>>> would work as well.
>>>> 
>>>>> 
>>>>> Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
>>>>> Signed-off-by: Vinod Koul <vkoul@kernel.org>
>>>>> ---
>>>>>  include/net/dsa.h | 1 +
>>>>>  net/dsa/dsa2.c    | 1 +
>>>>>  net/dsa/slave.c   | 5 ++++-
>>>>>  3 files changed, 6 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/include/net/dsa.h b/include/net/dsa.h
>>>>> index b3eefe8e18fd..aa24ce756679 100644
>>>>> --- a/include/net/dsa.h
>>>>> +++ b/include/net/dsa.h
>>>>> @@ -198,6 +198,7 @@ struct dsa_port {
>>>>>      unsigned int        index;
>>>>>      const char        *name;
>>>>>      const struct dsa_port    *cpu_dp;
>>>>> +    const char        *mac;
>>>>>      struct device_node    *dn;
>>>>>      unsigned int        ageing_time;
>>>>>      u8            stp_state;
>>>>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>>>>> index a1917025e155..afb7d9fa42f6 100644
>>>>> --- a/net/dsa/dsa2.c
>>>>> +++ b/net/dsa/dsa2.c
>>>>> @@ -261,6 +261,7 @@ static int dsa_port_setup(struct dsa_port *dp)
>>>>>      int err = 0;
>>>>> 
>>>>>      memset(&dp->devlink_port, 0, sizeof(dp->devlink_port));
>>>>> +    dp->mac = of_get_mac_address(dp->dn);
>>>>> 
>>>>>      if (dp->type != DSA_PORT_TYPE_UNUSED)
>>>>>          err = devlink_port_register(ds->devlink, 
>>>>> &dp->devlink_port,
>>>>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>>>>> index a3fcc1d01615..8e64c4e947c6 100644
>>>>> --- a/net/dsa/slave.c
>>>>> +++ b/net/dsa/slave.c
>>>>> @@ -1308,7 +1308,10 @@ int dsa_slave_create(struct dsa_port *port)
>>>>>      slave_dev->features = master->vlan_features | NETIF_F_HW_TC;
>>>>>      slave_dev->hw_features |= NETIF_F_HW_TC;
>>>>>      slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
>>>>> -    eth_hw_addr_inherit(slave_dev, master);
>>>>> +    if (port->mac && is_valid_ether_addr(port->mac))
>>>>> +        ether_addr_copy(slave_dev->dev_addr, port->mac);
>>>>> +    else
>>>>> +        eth_hw_addr_inherit(slave_dev, master);
>>>>>      slave_dev->priv_flags |= IFF_NO_QUEUE;
>>>>>      slave_dev->netdev_ops = &dsa_slave_netdev_ops;
>>>>>      slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
>>>>> 

  reply	other threads:[~2019-02-27  2:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 12:58 [PATCH] net: dsa: read mac address from DT for slave device Vinod Koul
2019-02-22 14:26 ` Andrew Lunn
2019-03-04  3:46   ` xiaofeis
2019-03-04  7:31     ` Vinod Koul
2019-03-04 13:18     ` Andrew Lunn
2019-02-22 15:43 ` Florian Fainelli
2019-02-25 13:28   ` xiaofeis
2019-02-25 17:27     ` Florian Fainelli
2019-02-26  7:45       ` xiaofeis
2019-02-27  2:04         ` xiaofeis [this message]
2019-02-27  3:13           ` Florian Fainelli
2019-02-28  2:23             ` xiaofeis
2019-02-28  3:54               ` Florian Fainelli
2019-03-04  3:48                 ` xiaofeis
2019-03-27  3:56                 ` xiaofeis
2019-02-27  6:57           ` xiaofeis

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=9962d7a13bb25c88cc42b3f4dd68cee7@codeaurora.org \
    --to=xiaofeis@codeaurora.org \
    --cc=andrew@lunn.ch \
    --cc=bjorn.andersson@linaro.org \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=niklas.cassel@linaro.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vkoul@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).