Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: Make VTU miss violations less spammy

[Florian Fainelli <f.fainelli@gmail.com>]

On 03/27/2018 02:59 PM, Andrew Lunn wrote:
> VTU miss violations can happen under normal conditions. Don't spam the
> kernel log. The statistics counter will indicate it is happening, if
> anybody is interested.
> 
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>

Reported-by: Florian Fainelli <f.fainelli@gmail.com>

> ---
>  drivers/net/dsa/mv88e6xxx/global1_vtu.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/global1_vtu.c b/drivers/net/dsa/mv88e6xxx/global1_vtu.c
> index 2cbaf946e7ed..e0f1b4f6e29f 100644
> --- a/drivers/net/dsa/mv88e6xxx/global1_vtu.c
> +++ b/drivers/net/dsa/mv88e6xxx/global1_vtu.c
> @@ -547,11 +547,9 @@ static irqreturn_t mv88e6xxx_g1_vtu_prob_irq_thread_fn(int irq, void *dev_id)
>  		chip->ports[spid].vtu_member_violation++;
>  	}
>  
> -	if (val & MV88E6XXX_G1_VTU_OP_MISS_VIOLATION) {
> -		dev_err_ratelimited(chip->dev, "VTU miss violation for vid %d, source port %d\n",
> -				    entry.vid, spid);

Why not keep it as a dev_dbg() message? Ideally we would want to keep
those message around when the port is enslaved to a bridge, and vlan
filtering is enabled. In other cases, I agree this is just spam with the
current error level.

> +	if (val & MV88E6XXX_G1_VTU_OP_MISS_VIOLATION)
>  		chip->ports[spid].vtu_miss_violation++;
> -	}
> +
>  	mutex_unlock(&chip->reg_lock);
>  
>  	return IRQ_HANDLED;
> 


-- 
Florian