From: Arınç ÜNAL <arinc.unal@arinc9.com>

Every bit of the CPU port bitmap for MT7531 and the switch on the MT7988
SoC represents a CPU port to trap frames to. Currently only the bit that
corresponds to the first found CPU port is set on the bitmap. Introduce the
MT7531_CPU_PMAP macro to individually set the bits of the CPU port bitmap.
Set the CPU port bitmap for MT7531 and the switch on the MT7988 SoC on
mt753x_cpu_port_enable() which runs on a loop for each CPU port. Add
comments to explain this.

According to the document MT7531 Reference Manual for Development Board
v1.0, the MT7531_CPU_PMAP bits are unset after reset so no need to clear it
beforehand. Since there's currently no public document for the switch on
the MT7988 SoC, I assume this is also the case for this switch.

Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 drivers/net/dsa/mt7530.c | 15 ++++++++-------
 drivers/net/dsa/mt7530.h |  3 ++-
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 58d8738d94d3..0b513e3628fe 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -963,6 +963,13 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
 		mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_MASK, MT7530_CPU_EN |
 			   MT7530_CPU_PORT(port));
 
+	/* Add the CPU port to the CPU port bitmap for MT7531 and the switch on
+	 * the MT7988 SoC. Any frames set for trapping to CPU port will be
+	 * trapped to the CPU port the user port is affine to.
+	 */
+	if (priv->id == ID_MT7531 || priv->id == ID_MT7988)
+		mt7530_set(priv, MT7531_CFC, MT7531_CPU_PMAP(BIT(port)));
+
 	/* CPU port gets connected to all user ports of
 	 * the switch.
 	 */
@@ -2315,15 +2322,9 @@ static int
 mt7531_setup_common(struct dsa_switch *ds)
 {
 	struct mt7530_priv *priv = ds->priv;
-	struct dsa_port *cpu_dp;
 	int ret, i;
 
-	/* BPDU to CPU port */
-	dsa_switch_for_each_cpu_port(cpu_dp, ds) {
-		mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
-			   BIT(cpu_dp->index));
-		break;
-	}
+	/* Trap BPDUs to the CPU port(s) */
 	mt7530_rmw(priv, MT753X_BPC, MT753X_BPDU_PORT_FW_MASK,
 		   MT753X_BPDU_CPU_ONLY);
 
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 5ebb942b07ef..fd2a2f726b8a 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -53,7 +53,8 @@ enum mt753x_id {
 #define  MT7531_MIRROR_MASK		(0x7 << 16)
 #define  MT7531_MIRROR_PORT_GET(x)	(((x) >> 16) & 0x7)
 #define  MT7531_MIRROR_PORT_SET(x)	(((x) & 0x7) << 16)
-#define  MT7531_CPU_PMAP_MASK		GENMASK(7, 0)
+#define  MT7531_CPU_PMAP(x)		((x) & 0xff)
+#define  MT7531_CPU_PMAP_MASK		MT7531_CPU_PMAP(~0)
 
 #define MT753X_MIRROR_REG(id)		((((id) == ID_MT7531) || ((id) == ID_MT7988)) ?	\
 					 MT7531_CFC : MT753X_MFC)
-- 
2.39.2

On Mon, May 22, 2023 at 03:15:27PM +0300, arinc9.unal@gmail.com wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> Every bit of the CPU port bitmap for MT7531 and the switch on the MT7988
> SoC represents a CPU port to trap frames to. Currently only the bit that
> corresponds to the first found CPU port is set on the bitmap. Introduce the
> MT7531_CPU_PMAP macro to individually set the bits of the CPU port bitmap.
> Set the CPU port bitmap for MT7531 and the switch on the MT7988 SoC on
> mt753x_cpu_port_enable() which runs on a loop for each CPU port. Add
> comments to explain this.
> 
> According to the document MT7531 Reference Manual for Development Board
> v1.0, the MT7531_CPU_PMAP bits are unset after reset so no need to clear it
> beforehand. Since there's currently no public document for the switch on
> the MT7988 SoC, I assume this is also the case for this switch.
> 
> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---

Is this supposed to be a bug fix? (incompatibility with past or future
device trees also counts as bugs) If so, it needs a Fixes: tag and to be
targeted towards the "net" tree. Also, the impact of the current behavior
and of the change need to be explained better.

>  drivers/net/dsa/mt7530.c | 15 ++++++++-------
>  drivers/net/dsa/mt7530.h |  3 ++-
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 58d8738d94d3..0b513e3628fe 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -963,6 +963,13 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
>  		mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_MASK, MT7530_CPU_EN |
>  			   MT7530_CPU_PORT(port));
>  
> +	/* Add the CPU port to the CPU port bitmap for MT7531 and the switch on
> +	 * the MT7988 SoC. Any frames set for trapping to CPU port will be
> +	 * trapped to the CPU port the user port is affine to.
> +	 */
> +	if (priv->id == ID_MT7531 || priv->id == ID_MT7988)
> +		mt7530_set(priv, MT7531_CFC, MT7531_CPU_PMAP(BIT(port)));
> +

Stylistically, the existence of an indirect call to priv->info->cpu_port_config()
per switch family is a bit dissonant with an explicit check for device id later
in the same function.

>  	/* CPU port gets connected to all user ports of
>  	 * the switch.
>  	 */
> @@ -2315,15 +2322,9 @@ static int
>  mt7531_setup_common(struct dsa_switch *ds)
>  {
>  	struct mt7530_priv *priv = ds->priv;
> -	struct dsa_port *cpu_dp;
>  	int ret, i;
>  
> -	/* BPDU to CPU port */
> -	dsa_switch_for_each_cpu_port(cpu_dp, ds) {
> -		mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
> -			   BIT(cpu_dp->index));
> -		break;
> -	}
> +	/* Trap BPDUs to the CPU port(s) */
>  	mt7530_rmw(priv, MT753X_BPC, MT753X_BPDU_PORT_FW_MASK,
>  		   MT753X_BPDU_CPU_ONLY);
>  
> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
> index 5ebb942b07ef..fd2a2f726b8a 100644
> --- a/drivers/net/dsa/mt7530.h
> +++ b/drivers/net/dsa/mt7530.h
> @@ -53,7 +53,8 @@ enum mt753x_id {
>  #define  MT7531_MIRROR_MASK		(0x7 << 16)
>  #define  MT7531_MIRROR_PORT_GET(x)	(((x) >> 16) & 0x7)
>  #define  MT7531_MIRROR_PORT_SET(x)	(((x) & 0x7) << 16)
> -#define  MT7531_CPU_PMAP_MASK		GENMASK(7, 0)
> +#define  MT7531_CPU_PMAP(x)		((x) & 0xff)

You can leave this as ((x) & GENMASK(7, 0))

> +#define  MT7531_CPU_PMAP_MASK		MT7531_CPU_PMAP(~0)

There's no other user of MT7531_CPU_PMAP_MASK, you can remove this.

>  
>  #define MT753X_MIRROR_REG(id)		((((id) == ID_MT7531) || ((id) == ID_MT7988)) ?	\
>  					 MT7531_CFC : MT753X_MFC)
> -- 
> 2.39.2
> 

On 26.05.2023 18:51, Vladimir Oltean wrote:
> On Mon, May 22, 2023 at 03:15:27PM +0300, arinc9.unal@gmail.com wrote:
>> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>>
>> Every bit of the CPU port bitmap for MT7531 and the switch on the MT7988
>> SoC represents a CPU port to trap frames to. Currently only the bit that
>> corresponds to the first found CPU port is set on the bitmap. Introduce the
>> MT7531_CPU_PMAP macro to individually set the bits of the CPU port bitmap.
>> Set the CPU port bitmap for MT7531 and the switch on the MT7988 SoC on
>> mt753x_cpu_port_enable() which runs on a loop for each CPU port. Add
>> comments to explain this.
>>
>> According to the document MT7531 Reference Manual for Development Board
>> v1.0, the MT7531_CPU_PMAP bits are unset after reset so no need to clear it
>> beforehand. Since there's currently no public document for the switch on
>> the MT7988 SoC, I assume this is also the case for this switch.
>>
>> Tested-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
>> ---
> 
> Is this supposed to be a bug fix? (incompatibility with past or future
> device trees also counts as bugs) If so, it needs a Fixes: tag and to be
> targeted towards the "net" tree. Also, the impact of the current behavior
> and of the change need to be explained better.

Yes, this fixes a bug for future devicetrees. I will send this to net 
with a more detailed explanation, thanks.

> 
>>   drivers/net/dsa/mt7530.c | 15 ++++++++-------
>>   drivers/net/dsa/mt7530.h |  3 ++-
>>   2 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
>> index 58d8738d94d3..0b513e3628fe 100644
>> --- a/drivers/net/dsa/mt7530.c
>> +++ b/drivers/net/dsa/mt7530.c
>> @@ -963,6 +963,13 @@ mt753x_cpu_port_enable(struct dsa_switch *ds, int port)
>>   		mt7530_rmw(priv, MT753X_MFC, MT7530_CPU_MASK, MT7530_CPU_EN |
>>   			   MT7530_CPU_PORT(port));
>>   
>> +	/* Add the CPU port to the CPU port bitmap for MT7531 and the switch on
>> +	 * the MT7988 SoC. Any frames set for trapping to CPU port will be
>> +	 * trapped to the CPU port the user port is affine to.
>> +	 */
>> +	if (priv->id == ID_MT7531 || priv->id == ID_MT7988)
>> +		mt7530_set(priv, MT7531_CFC, MT7531_CPU_PMAP(BIT(port)));
>> +
> 
> Stylistically, the existence of an indirect call to priv->info->cpu_port_config()
> per switch family is a bit dissonant with an explicit check for device id later
> in the same function.

mt753x_cpu_port_enable() is not being called from 
priv->info->cpu_port_config() though. I'm not sure how I would do this 
without the device ID check here.

> 
>>   	/* CPU port gets connected to all user ports of
>>   	 * the switch.
>>   	 */
>> @@ -2315,15 +2322,9 @@ static int
>>   mt7531_setup_common(struct dsa_switch *ds)
>>   {
>>   	struct mt7530_priv *priv = ds->priv;
>> -	struct dsa_port *cpu_dp;
>>   	int ret, i;
>>   
>> -	/* BPDU to CPU port */
>> -	dsa_switch_for_each_cpu_port(cpu_dp, ds) {
>> -		mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
>> -			   BIT(cpu_dp->index));
>> -		break;
>> -	}
>> +	/* Trap BPDUs to the CPU port(s) */
>>   	mt7530_rmw(priv, MT753X_BPC, MT753X_BPDU_PORT_FW_MASK,
>>   		   MT753X_BPDU_CPU_ONLY);
>>   
>> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
>> index 5ebb942b07ef..fd2a2f726b8a 100644
>> --- a/drivers/net/dsa/mt7530.h
>> +++ b/drivers/net/dsa/mt7530.h
>> @@ -53,7 +53,8 @@ enum mt753x_id {
>>   #define  MT7531_MIRROR_MASK		(0x7 << 16)
>>   #define  MT7531_MIRROR_PORT_GET(x)	(((x) >> 16) & 0x7)
>>   #define  MT7531_MIRROR_PORT_SET(x)	(((x) & 0x7) << 16)
>> -#define  MT7531_CPU_PMAP_MASK		GENMASK(7, 0)
>> +#define  MT7531_CPU_PMAP(x)		((x) & 0xff)
> 
> You can leave this as ((x) & GENMASK(7, 0))

Now that I've read Russell's comment on the previous patch, the below 
would be even better?

MT7531_CPU_PMAP(x)		FIELD_PREP(MT7531_CPU_PMAP_MASK, x)

> 
>> +#define  MT7531_CPU_PMAP_MASK		MT7531_CPU_PMAP(~0)
> 
> There's no other user of MT7531_CPU_PMAP_MASK, you can remove this.

Should I do above or remove this?

Arınç

On Sun, Jun 04, 2023 at 11:21:48AM +0300, Arınç ÜNAL wrote:
> > Stylistically, the existence of an indirect call to priv->info->cpu_port_config()
> > per switch family is a bit dissonant with an explicit check for device id later
> > in the same function.
> 
> mt753x_cpu_port_enable() is not being called from priv->info->cpu_port_config()
> though.

Quite the other way around. I'm saying that mt753x_cpu_port_enable(),
the function whose logic you're changing, already has a mechanism to
execute code specific to one switch family.

> I'm not sure how I would do this without the device ID check here.

Hmm, by defining a new mt7530_cpu_port_config() procedure for ID_MT7621
and ID_MT7530?

Although in a different thread we are perhaps challenging the idea that
what is currently in priv->info->cpu_port_config() is useful - at least
half of it are manual invocations of phylink methods which are possibly
not needed. If after the removal of those, it no longer makes sense to
have priv->info->cpu_port_config() at all, then I'm not saying that the
explicit check for device id here doesn't make sense. Just that it's not
in harmony with what currently exists 3 lines above.

> > > -#define  MT7531_CPU_PMAP_MASK		GENMASK(7, 0)
> > > +#define  MT7531_CPU_PMAP(x)		((x) & 0xff)
> > 
> > You can leave this as ((x) & GENMASK(7, 0))
> 
> Now that I've read Russell's comment on the previous patch, the below would
> be even better?
> 
> MT7531_CPU_PMAP(x)		FIELD_PREP(MT7531_CPU_PMAP_MASK, x)
> 
> > 
> > > +#define  MT7531_CPU_PMAP_MASK		MT7531_CPU_PMAP(~0)
> > 
> > There's no other user of MT7531_CPU_PMAP_MASK, you can remove this.
> 
> Should I do above or remove this?

No specific preference. If you want to make this driver start using
FIELD_PREP() then go ahead.

On 4.06.2023 16:08, Vladimir Oltean wrote:
> On Sun, Jun 04, 2023 at 11:21:48AM +0300, Arınç ÜNAL wrote:
>>> Stylistically, the existence of an indirect call to priv->info->cpu_port_config()
>>> per switch family is a bit dissonant with an explicit check for device id later
>>> in the same function.
>>
>> mt753x_cpu_port_enable() is not being called from priv->info->cpu_port_config()
>> though.
> 
> Quite the other way around. I'm saying that mt753x_cpu_port_enable(),
> the function whose logic you're changing, already has a mechanism to
> execute code specific to one switch family.

Ah, makes sense.

> 
>> I'm not sure how I would do this without the device ID check here.
> 
> Hmm, by defining a new mt7530_cpu_port_config() procedure for ID_MT7621
> and ID_MT7530?
> 
> Although in a different thread we are perhaps challenging the idea that
> what is currently in priv->info->cpu_port_config() is useful - at least
> half of it are manual invocations of phylink methods which are possibly
> not needed. If after the removal of those, it no longer makes sense to
> have priv->info->cpu_port_config() at all, then I'm not saying that the
> explicit check for device id here doesn't make sense. Just that it's not
> in harmony with what currently exists 3 lines above.

Regardless of the outcome of that conversation, I would like to avoid 
structural changes like this since this patch will go to net.

> 
>>>> -#define  MT7531_CPU_PMAP_MASK		GENMASK(7, 0)
>>>> +#define  MT7531_CPU_PMAP(x)		((x) & 0xff)
>>>
>>> You can leave this as ((x) & GENMASK(7, 0))
>>
>> Now that I've read Russell's comment on the previous patch, the below would
>> be even better?
>>
>> MT7531_CPU_PMAP(x)		FIELD_PREP(MT7531_CPU_PMAP_MASK, x)
>>
>>>
>>>> +#define  MT7531_CPU_PMAP_MASK		MT7531_CPU_PMAP(~0)
>>>
>>> There's no other user of MT7531_CPU_PMAP_MASK, you can remove this.
>>
>> Should I do above or remove this?
> 
> No specific preference. If you want to make this driver start using
> FIELD_PREP() then go ahead.

Will do.

Arınç