linux-kernel - Re: [PATCH net-next] net: dsa: mt7530: support MDB and bridge flag operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <84bb93da-cc3b-d2a5-dda8-a8fb973c3bae@gmail.com>
Date:   Mon, 15 Mar 2021 13:44:02 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     DENG Qingfang <dqfext@...il.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Frank Wunderlich <frank-w@...lic-files.de>,
        René van Dorst <opensource@...rst.com>
Subject: Re: [PATCH net-next] net: dsa: mt7530: support MDB and bridge flag
 operations



On 3/15/2021 1:09 PM, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 01:03:10PM -0700, Florian Fainelli wrote:
>>
>>
>> On 3/15/2021 10:09 AM, DENG Qingfang wrote:
>>> Support port MDB and bridge flag operations.
>>>
>>> As the hardware can manage multicast forwarding itself, offload_fwd_mark
>>> can be unconditionally set to true.
>>>
>>> Signed-off-by: DENG Qingfang <dqfext@...il.com>
>>> ---
>>> Changes since RFC:
>>>   Replaced BR_AUTO_MASK with BR_FLOOD | BR_LEARNING
>>>
>>>  drivers/net/dsa/mt7530.c | 124 +++++++++++++++++++++++++++++++++++++--
>>>  drivers/net/dsa/mt7530.h |   1 +
>>>  net/dsa/tag_mtk.c        |  14 +----
>>>  3 files changed, 122 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
>>> index 2342d4528b4c..f765984330c9 100644
>>> --- a/drivers/net/dsa/mt7530.c
>>> +++ b/drivers/net/dsa/mt7530.c
>>> @@ -1000,8 +1000,9 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
>>>  	mt7530_write(priv, MT7530_PVC_P(port),
>>>  		     PORT_SPEC_TAG);
>>>  
>>> -	/* Unknown multicast frame forwarding to the cpu port */
>>> -	mt7530_rmw(priv, MT7530_MFC, UNM_FFP_MASK, UNM_FFP(BIT(port)));
>>> +	/* Disable flooding by default */
>>> +	mt7530_rmw(priv, MT7530_MFC, BC_FFP_MASK | UNM_FFP_MASK | UNU_FFP_MASK,
>>> +		   BC_FFP(BIT(port)) | UNM_FFP(BIT(port)) | UNU_FFP(BIT(port)));
>>
>> It's not clear to me why this is appropriate especially when the ports
>> operated in standalone mode, can you expand a bit more on this?
> 
> We are in the function called "mt753x_cpu_port_enable" here. It's ok to
> apply this config for the CPU port.

Because the user ports will flood unknown traffic and we have mediatek
tags enabled presumably, so all traffic is copied to the CPU port, OK.
-- 
Florian