netdev - Re: [PATCH net-next 4/5 v2] net: dsa: rtl8366rb: Support flood control

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <06adb47b-45a7-175d-759b-a2f22d208a27@bang-olufsen.dk>
Date:   Mon, 30 Aug 2021 23:42:55 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Vladimir Oltean <olteanv@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>
CC:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Mauri Sandberg <sandberg@...lfence.com>,
        DENG Qingfang <dqfext@...il.com>
Subject: Re: [PATCH net-next 4/5 v2] net: dsa: rtl8366rb: Support flood
 control

On 8/31/21 12:43 AM, Vladimir Oltean wrote:
> On Mon, Aug 30, 2021 at 11:48:58PM +0200, Linus Walleij wrote:
>> Now that we have implemented bridge flag handling we can easily
>> support flood (storm) control as well so let's do it.
>>
>> Cc: Vladimir Oltean <olteanv@...il.com>
>> Cc: Alvin Šipraga <alsi@...g-olufsen.dk>
>> Cc: Mauri Sandberg <sandberg@...lfence.com>
>> Cc: DENG Qingfang <dqfext@...il.com>
>> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
>> ---
>> ChangeLog v1->v2:
>> - New patch
>> ---
>>   drivers/net/dsa/rtl8366rb.c | 38 ++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
>> index 2cadd3e57e8b..4cb0e336ce6b 100644
>> --- a/drivers/net/dsa/rtl8366rb.c
>> +++ b/drivers/net/dsa/rtl8366rb.c
>> @@ -149,6 +149,11 @@
>>   
>>   #define RTL8366RB_VLAN_INGRESS_CTRL2_REG	0x037f
>>   
>> +#define RTL8366RB_STORM_BC_CTRL			0x03e0
>> +#define RTL8366RB_STORM_MC_CTRL			0x03e1
>> +#define RTL8366RB_STORM_UNDA_CTRL		0x03e2
>> +#define RTL8366RB_STORM_UNMC_CTRL		0x03e3
>> +
>>   /* LED control registers */
>>   #define RTL8366RB_LED_BLINKRATE_REG		0x0430
>>   #define RTL8366RB_LED_BLINKRATE_MASK		0x0007
>> @@ -1158,7 +1163,8 @@ rtl8366rb_port_pre_bridge_flags(struct dsa_switch *ds, int port,
>>   				struct netlink_ext_ack *extack)
>>   {
>>   	/* We support enabling/disabling learning */
>> -	if (flags.mask & ~(BR_LEARNING))
>> +	if (flags.mask & ~(BR_LEARNING | BR_BCAST_FLOOD |
>> +                           BR_MCAST_FLOOD | BR_FLOOD))
> 
> Spaces instead of tabs here?
> 
>>   		return -EINVAL;
>>   
>>   	return 0;
>> @@ -1180,6 +1186,36 @@ rtl8366rb_port_bridge_flags(struct dsa_switch *ds, int port,
>>   			return ret;
>>   	}
>>   
>> +	if (flags.mask & BR_BCAST_FLOOD) {
>> +		ret = regmap_update_bits(smi->map, RTL8366RB_STORM_BC_CTRL,
>> +					 BIT(port),
>> +					 (flags.val & BR_BCAST_FLOOD) ? BIT(port) : 0);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>> +	if (flags.mask & BR_MCAST_FLOOD) {
>> +		ret = regmap_update_bits(smi->map, RTL8366RB_STORM_MC_CTRL,
>> +					 BIT(port),
>> +					 (flags.val & BR_MCAST_FLOOD) ? BIT(port) : 0);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>> +	/* Enable/disable both types of unicast floods */
>> +	if (flags.mask & BR_FLOOD) {
>> +		ret = regmap_update_bits(smi->map, RTL8366RB_STORM_UNDA_CTRL,
>> +					 BIT(port),
>> +					 (flags.val & BR_FLOOD) ? BIT(port) : 0);
>> +		if (ret)
>> +			return ret;
>> +		ret = regmap_update_bits(smi->map, RTL8366RB_STORM_UNMC_CTRL,
>> +					 BIT(port),
>> +					 (flags.val & BR_FLOOD) ? BIT(port) : 0);
>> +		if (ret)
>> +			return ret;
> 
> UNDA and UNMC?

Ah, I was also fooled by this. UN is not unicast. It means "unknown 
destination address" and "unknown multicast address".

So, UNMC should go under BR_MCAST_FLOOD?

> 
>> +	}
>> +
>>   	return 0;
>>   }
>>   
>> -- 
>> 2.31.1
>>
>