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 <and...@lunn.ch>
Reported-by: Florian Fainelli <f.faine...@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
