linux-kernel - Re: [PATCH net-next 12/13] net: dsa: lantiq_gswip: Add and use a GSWIP_TABLE_MAC_BRIDGE

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: <ae0811c79a126e9f034beccf37e61991@dev.tdt.de>
Date: Fri, 07 Jun 2024 16:27:04 +0200
From: Martin Schiller <ms@....tdt.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: martin.blumenstingl@...glemail.com, hauke@...ke-m.de, andrew@...n.ch,
 f.fainelli@...il.com, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, pabeni@...hat.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 12/13] net: dsa: lantiq_gswip: Add and use a
 GSWIP_TABLE_MAC_BRIDGE_FID macro

On 2024-06-07 13:36, Vladimir Oltean wrote:
> On Thu, Jun 06, 2024 at 10:52:33AM +0200, Martin Schiller wrote:
>> From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
>> 
>> Only bits [5:0] in mac_bridge.key[3] are reserved for the FID. Add a
>> macro so this becomes obvious when reading the driver code.
>> 
>> Signed-off-by: Martin Blumenstingl 
>> <martin.blumenstingl@...glemail.com>
>> ---
>>  drivers/net/dsa/lantiq_gswip.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/dsa/lantiq_gswip.c 
>> b/drivers/net/dsa/lantiq_gswip.c
>> index f2faee112e33..4bb894e75b81 100644
>> --- a/drivers/net/dsa/lantiq_gswip.c
>> +++ b/drivers/net/dsa/lantiq_gswip.c
>> @@ -238,6 +238,7 @@
>>  #define GSWIP_TABLE_MAC_BRIDGE		0x0b
>>  #define  GSWIP_TABLE_MAC_BRIDGE_STATIC	BIT(0)		/* Static not, aging 
>> entry */
>>  #define  GSWIP_TABLE_MAC_BRIDGE_PORT	GENMASK(7, 4)	/* Port on learned 
>> entries */
>> +#define  GSWIP_TABLE_MAC_BRIDGE_FID	GENMASK(5, 0)	/* Filtering 
>> identifier */
>> 
>>  #define XRX200_GPHY_FW_ALIGN	(16 * 1024)
>> 
>> @@ -1385,7 +1386,7 @@ static int gswip_port_fdb(struct dsa_switch *ds, 
>> int port,
>>  	mac_bridge.key[0] = addr[5] | (addr[4] << 8);
>>  	mac_bridge.key[1] = addr[3] | (addr[2] << 8);
>>  	mac_bridge.key[2] = addr[1] | (addr[0] << 8);
>> -	mac_bridge.key[3] = fid;
>> +	mac_bridge.key[3] = FIELD_PREP(GSWIP_TABLE_MAC_BRIDGE_FID, fid);
>>  	mac_bridge.val[0] = add ? BIT(port) : 0; /* port map */
>>  	mac_bridge.val[1] = GSWIP_TABLE_MAC_BRIDGE_STATIC;
>>  	mac_bridge.valid = add;
>> --
>> 2.39.2
> 
> On second thought, I disagree with the naming scheme of the
> GSWIP_TABLE_MAC_BRIDGE_* macros. It is completely non obvious that they
> are non-overlapping, because they have the same name prefix, but:
> _STATIC applies to gswip_pce_table_entry :: val[1]
> _PORT applies to gswip_pce_table_entry :: val[0]
> _FID applies to gswip_pce_table_entry :: key[3]
> 
> I think it's all too easy to use the wrong macro on the wrong register 
> field.
> If the macros incorporated names like VAL1, KEY3 etc, it would be much
> more obvious. Could you please do that?

OK, so I'll change the macro names to

GSWIP_TABLE_MAC_BRIDGE_KEY3_FID
GSWIP_TABLE_MAC_BRIDGE_VAL0_PORT
GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC

Also the comment of GSWIP_TABLE_MAC_BRIDGE_VAL1_STATIC should be changed 
to
/* Static, not aging entry */

While looking again at this diff above, I noticed that val[0] is set
incorrectly. Shouldn't it be either "port << 4" or (after the previous 
patch)
"FIELD_PREP(GSWIP_TABLE_MAC_BRIDGE_PORT, port);" instead of "BIT(port)"?