Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: MY1/8bnyhRLbIxxiQe7hzBwhAEMc1kE0v0ibPOsaD04QOdYFArX+bXBNz2DACy4mxF3dzegbfo
 Udklacoj5AQwWFOTtJv3zVimz6gRI7/mbMCmg83n6cSY8R4DRSJv46cc+dcImX4MrULc1DyMqF
 UZ1WWH1WzBKUdNDjvhghyZTr6zMXCJSvg2/mcRdyjnPG/NBlitwz/z04LAhLTJ443GlfWsdzoY
 KIy600DHd3rcgvtmAUm3RqvrKssawB9tFI0ebLL0QMycT2vDi7Uqt3VqO0qAsItI6kaQrJ2OTx
 YLNsKHDqM8ZXEfj3F7POVBzI
Subject: Re: [PATCH] can: at91_can: fix passive-state AERR flooding
To:     Brandon Maier <brandon.maier@rockwellcollins.com>
CC:     Wolfgang Grandegger <wg@grandegger.com>,
        Marc Kleine-Budde <mkl@pengutronix.de>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        "Ludovic Desroches" <ludovic.desroches@microchip.com>,
        "open list:CAN NETWORK DRIVERS" <linux-can@vger.kernel.org>,
        "open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
        "moderated list:ARM/Microchip (AT91) SoC support" 
        <linux-arm-kernel@lists.infradead.org>,
        open list <linux-kernel@vger.kernel.org>
References: <20211005183023.109328-1-brandon.maier@rockwellcollins.com>
From:   Nicolas Ferre <nicolas.ferre@microchip.com>
Organization: microchip
Message-ID: <ac0aaa78-d258-fb22-300a-43851006b5c5@microchip.com>
Date:   Thu, 7 Oct 2021 15:28:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20211005183023.109328-1-brandon.maier@rockwellcollins.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 05/10/2021 at 20:30, Brandon Maier wrote:
> When the at91_can is a single node on the bus and a user attempts to
> transmit, the can state machine will report ack errors and increment the
> transmit error count until it reaches the passive-state. Per the
> specification, it will then transmit with a passive error, but will stop
> incrementing the transmit error count. This results in the host machine
> being flooded with the AERR interrupt forever, or until another node
> rejoins the bus.
> 
> To prevent the AERR flooding, disable the AERR interrupt when we are in
> passive mode.
> 
> Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>

Even if I'm not familiar with the matter, the explanation above makes sense:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>

Thanks Brandon, best regards,
   Nicolas

> ---
>   drivers/net/can/at91_can.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
> index b06af90a9964..2a8831127bd0 100644
> --- a/drivers/net/can/at91_can.c
> +++ b/drivers/net/can/at91_can.c
> @@ -804,8 +804,13 @@ static int at91_poll(struct napi_struct *napi, int quota)
>                  work_done += at91_poll_err(dev, quota - work_done, reg_sr);
> 
>          if (work_done < quota) {
> -               /* enable IRQs for frame errors and all mailboxes >= rx_next */
> +               /* enable IRQs for frame errors and all mailboxes >= rx_next,
> +                * disable the ack error in passive mode to avoid flooding
> +                * ourselves with interrupts
> +                */
>                  u32 reg_ier = AT91_IRQ_ERR_FRAME;
> +               if (priv->can.state == CAN_STATE_ERROR_PASSIVE)
> +                       reg_ier &= ~AT91_IRQ_AERR;
> 
>                  reg_ier |= get_irq_mb_rx(priv) & ~AT91_MB_MASK(priv->rx_next);
> 
> --
> 2.30.2
> 


-- 
Nicolas Ferre