From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A321C43381 for ; Thu, 28 Feb 2019 03:54:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1FADD20851 for ; Thu, 28 Feb 2019 03:54:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nZoH9vaX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730600AbfB1DyQ (ORCPT ); Wed, 27 Feb 2019 22:54:16 -0500 Received: from mail-pf1-f196.google.com ([209.85.210.196]:39868 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730131AbfB1DyQ (ORCPT ); Wed, 27 Feb 2019 22:54:16 -0500 Received: by mail-pf1-f196.google.com with SMTP id i20so9034614pfo.6; Wed, 27 Feb 2019 19:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4rbke1DiAc1crkQ5Rug0yp/OXbF/0398Mav73SS7QvM=; b=nZoH9vaXGhvr+B+YIVTJX1gW3D3tZq5lSZ6HLELbJwa+3tfZudYQC7lUvMPjeXQUgB D61uRx2z0/hWz6easszxxKYGDhMr9pNdMeFJFhFE8KkBkdzR6DmHmHoFxk9cg5CO4PYV CIaOkcwbi9n22QsW9tSILfPaXq0EaQv/Mneed3unHpn/aRX8+JUQWvTCVrTnLcc64jjv a5yMfgE2UNdx1YhSRTgseoTzAwp6YN6AClrxlpvco7ZBQ7cItJjm72KUKVMSnVJM59J4 4slJe0o36G5mIkR4sy2CWyrMvGg+LAC+BEQiI9hBpPWOhs3/5Myg5piGo6ZfeaesLV0X jtMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4rbke1DiAc1crkQ5Rug0yp/OXbF/0398Mav73SS7QvM=; b=rupHr3kBRJSjQmK9gx75SAkMxyAqpReC/lwp4J9Tq0kQVVQbOcHOHlJTE2NQL2S2NN NlJYglJqhcn/DP4Z4oa8cg5Ot2fURzaImRyt74ps3S7qr89KR7j8p7jdYCgVxp/s2Wip ZruTKnC0S876Z4c4rvicM2M00JGjjtd5xQXC4MCPFOvCp3eEtecGDVDMfnCu7MBzarpv x7MHihIFG8YwDD3HJdgP/boTqjKtjjmIuSI/ZWISnFhB13wRf53y7pLZj4bvfpcEXYPu wp9gRvJCl5vvY5ofw6xZZOv3I0dWRuNIfLsi3uFyBadgYZgmntGiTpJC2DC/DzZp0kD3 Krog== X-Gm-Message-State: AHQUAub8P9I8g99udNEAmL2A4aoRDLLBwcebLzNojpcuUK2/4Rzr703D I/NfhrSCcEpEo63Uftapi4PASn/X X-Google-Smtp-Source: AHgI3IbiiF0S0+73Prz+4aHOZbj0H97jAJsdVQsA9SB5ZJBE0j9uDZmJsf1IpLGfUtioiuYm4nUtRw== X-Received: by 2002:a62:398d:: with SMTP id u13mr5255891pfj.32.1551326054293; Wed, 27 Feb 2019 19:54:14 -0800 (PST) Received: from [10.230.1.150] ([192.19.228.250]) by smtp.gmail.com with ESMTPSA id i72sm45060887pfj.147.2019.02.27.19.54.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 19:54:13 -0800 (PST) Subject: Re: [PATCH] net: dsa: read mac address from DT for slave device To: xiaofeis@codeaurora.org Cc: Vinod Koul , "David S. Miller" , linux-arm-msm@vger.kernel.org, Bjorn Andersson , Andrew Lunn , Vivien Didelot , Niklas Cassel , netdev@vger.kernel.org References: <20190222125815.12866-1-vkoul@kernel.org> <9baf097f-37ea-2bef-92dd-25a7040a16ed@gmail.com> <967ec7b53270f1e29bb25e087c1a67a4@codeaurora.org> <9962d7a13bb25c88cc42b3f4dd68cee7@codeaurora.org> <9f0a1ca6-2efd-a4e6-77b5-14b68a3a791d@gmail.com> <399272053c9e69386e709923544ba0d6@codeaurora.org> From: Florian Fainelli Openpgp: preference=signencrypt Autocrypt: addr=f.fainelli@gmail.com; keydata= mQENBFPAG8ABCAC3EO02urEwipgbUNJ1r6oI2Vr/+uE389lSEShN2PmL3MVnzhViSAtrYxeT M0Txqn1tOWoIc4QUl6Ggqf5KP6FoRkCrgMMTnUAINsINYXK+3OLe7HjP10h2jDRX4Ajs4Ghs JrZOBru6rH0YrgAhr6O5gG7NE1jhly+EsOa2MpwOiXO4DE/YKZGuVe6Bh87WqmILs9KvnNrQ PcycQnYKTVpqE95d4M824M5cuRB6D1GrYovCsjA9uxo22kPdOoQRAu5gBBn3AdtALFyQj9DQ KQuc39/i/Kt6XLZ/RsBc6qLs+p+JnEuPJngTSfWvzGjpx0nkwCMi4yBb+xk7Hki4kEslABEB AAG0KEZsb3JpYW4gRmFpbmVsbGkgPGZhaW5lbGxpQGJyb2FkY29tLmNvbT6JAccEEAECALEF AlPAG9YXCgABv0jL/n0t8VEFmtDa8j7qERo7AN0gFAAAAAAAFgABa2V5LXVzYWdlLW1hc2tA cGdwLmNvbY4wFIAAAAAAIAAHcHJlZmVycmVkLWVtYWlsLWVuY29kaW5nQHBncC5jb21wZ3Bt aW1lCAsJCAcDAgEKAhkBBReAAAAAGRhsZGFwOi8va2V5cy5icm9hZGNvbS5jb20FGwMAAAAD FgIBBR4BAAAABBUICQoACgkQgTG1xCm8ZqD+Dgf9HhhzqvJYIPomNeg+ll7/TbzWb871E+HQ TaufJQFQwLEbgdFSZO2uj4UqfDpCyTwtHTVMJogWt3pCAE1sadeIY8OlT6918ofKIl8AiHj2 BlfL7ASZ5wzkRMt/4TZoinq9O1tPEynb5G6PdZTV3UQtmSGnpt2EOu7KtRJsnThBiXoOO9TJ Asg4vXJ0ZM1y/MPhQlZbPCHQZFe1gaVWBPLGnLyWyeprqgSLWHaGqrUhlfK1sLuJK1bjYDCI NetK0pS4cA4ZJgogr5FrtV64R19zLl02mt/Yj7rAmjC3ZBuwVi3V35kD8Kd4d9QM2apsiILV bzGbtVCSUgvxI+1SsJEm3bkBDQRTwBvBAQgArGvvWip77T4xgJztZp9YRylAcVTC9gtx0Gg6 eYk/EPANGm9TkuGpI++T/Il2H2TjFQNC7eubWohbYj0+6Tmf8nP+VmyobDxPXcMrK7x4xy9o D+Kub2Vf0SXbsM8fL/SqzGbFWZSm73L1L4GZoxvYIz0i7LExYSX2u5YVLaMBaH9HwKt2cvr7 MuTrRHtcbOZImoXT29g2UnoF1uwxYNeRhZY/lRvVkkY0lDipPuDwg3SpfHMtCybPq1uAswQd gEbHzRsEXwCR1OF3pIuGt4I3tSEhH/k1caqi0BlqjbGUOkku44xC2gf1ZU267FBBkdV3yJ/7 KnrJEnkMCYhS3kII9wARAQABiQJBBBgBAgErBQJTwBvCBRsMAAAAwF0gBBkBCAAGBQJTwBvB AAoJEJNgBqiYLw9VDRUIAJaTef6hsUAESnlGDpC+ymL2RZdzAJx9lXjU4hhaFcyhznuyyMJq d3mehmLxsqDRvHDiqyD71w2Bnc838MVZw0pwBPdnb/h9Ocmp0lL/9hwSGWvy4az5lYVyoA9u 14UIzh0YNGu6jr0isd/LJAbHXqwJwWWs3y8PTrpEp68V6lv+aXt5gR03lJEAvIR1Awp4JJ/e Z5y12gQISp0X8xal9YhhDWER92YLYrO2b6Hc2S31lAupzfCw8lmZsP1PRz1GmF/KmDD9J9N/ b8IehhWQqrBQjMjn2K2XkvN75HnAMHKFYfHZR3ZHtK52ZP1crV7THtbtrnPXVDq+vO4QPmdC +SEACgkQgTG1xCm8ZqC6BwgAl3kRh7oozpjpG8jpO8en5CBtTl3G+OpKJK9qbQyzdCsuJ0K1 qe1wZPZbP/Y+VtmqSgnExBzjStt9drjFBK8liPQZalp2sMlS9S7csSy6cMLF1auZubAZEqpm tpXagbtgR12YOo57Reb83F5KhtwwiWdoTpXRTx/nM0cHtjjrImONhP8OzVMmjem/B68NY++/ qt0F5XTsP2zjd+tRLrFh3W4XEcLt1lhYmNmbJR/l6+vVbWAKDAtcbQ8SL2feqbPWV6VDyVKh ya/EEq0xtf84qEB+4/+IjCdOzDD3kDZJo+JBkDnU3LBXw4WCw3QhOXY+VnhOn2EcREN7qdAK w0j9Sw== Message-ID: Date: Wed, 27 Feb 2019 19:54:05 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <399272053c9e69386e709923544ba0d6@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2/27/2019 6:23 PM, xiaofeis@codeaurora.org wrote: > On 2019-02-27 11:13, Florian Fainelli wrote: >> On 2/26/2019 6:04 PM, xiaofeis@codeaurora.org wrote: >>> 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ð0.2), i think this is similar with >>> DSA slave interfaces. >> >> Yes it is a similar use case, and in both cases there is no really a >> functional need for a separate MAC address for lan/eth0.1 or wan/eth0.2 >> since the switch should be configured to perform IVL (Individual VLAN >> Learning) and would determine the egress port just fine based on the MAC >> DA. Because it is an established practice does not mean we should not >> challenge it :). >> >> My issue with your change is that because DSA is meant to be a flexible >> framework we do not know the type/nature of DSA master network device >> that is going to be used. That DSA master network device may or may not >> have it own MAC DA filtering capability. Having to filter its own MAC >> address is fine and a well established behavior, having to filter for >> more than one unicast address starts to be questionable and eats up >> filter space that could be better used for filtering MC addresses >> instead. Another possible concern is a station trying to spoof the MAC >> address, some switches may support protecting only one UC/management MAC >> address, so having more than one could create security attack surfaces. >> >> To give you an example, I work with 3 generations of DSA master network >> controllers (bcmgenet and bcmsysport drivers). >> >> - GENET supports 17 perfect filters, but we must include its own MAC >> address, the broadcast address and that leaves only 15 filters for MC >> >> - SYSTEMPORT is always attached to a switch but supports filtering the >> MAC DA based on its own MAC and then it is in promiscuous mode >> >> So with your scheme, we would leave only 13 filters for MC on GENET and >> we would putting the interface in promiscuous mode for SYSTEMPORT. >> >> Until we have a better switch-side filtering framework (and this is >> being worked on right now), I would prefer that we defer accepting those >> type of features. Andrew and Vivien might feel differently about that >> though. > This patch is just add one more option, if there is valid mac address > populated > in the DTS, then use it or else still inherti from master. I don't think > it will > break the DSA flexible framework. I think this change make DSA more > flexible on > MAC address setting. > Many cusomter use some of our QCA chips, some direclty use DSA, some use > internal similar > mechanism(one netdevice for each switch port with swtichdev), we didn't > see any limiation > when they populiate the mac address for each port in DTS with only one > HW mac controller. > So my  opinion is this patch is want to add a option which is already > used in many > products, this change does not break anything, developer/customer can > chose use or not. As I wrote, I am not totally opposed to it, I would prefer we had a better infrastructure for UC/MC filtering in place before landing this change but that is not there yet, and won't happen over night. So please address Andrew's feedback to provide an update to the DSA binding document, repost and I will certainly Ack it this time. Please be considerate of people giving you feedback and do not try to circle back to your use case and just explaining in a different way than "works for me, accept it", because that's not going to work really well in the long run. Looking forward for more contributions on the qca8k driver, thanks! -- Florian