Re: flexcan napi poll and error frames

[David Jander <david@protonic.nl>]

Hi Andri,

On Fri, 24 Oct 2014 17:40:19 +0000
Andri Yngvason <andri.yngvason@marel.com> wrote:

> 
> On fös 24.okt 2014 16:36, Steffen Rose wrote:
> > Hello,
> >
> > Am Freitag, 24. Oktober 2014, 16:04:56 schrieben Sie:
> >>> We can do little if the CAN controller does not notify the Software
> >>>> via interrupt.
> >>> Yes, that's why I wanted to figure out if it's a controller problem or
> >>> not.
> >>> Turns out it's a controller problem, but perhaps we can work around it?
> >>> E.g. if we check esr for state changes every time someone transmits a
> >>> frame, both of these problems would go away. Would it be unacceptable
> >>> overhead to do so?
> >> I've just confirmed that this "fix" works, but only if berr-reporting is
> >> enabled.
> > Is this workaround working in case of an open CAN Bus?
> > (Ack error situation)
> Yes
> > The flexcan can generate an error interrupt after every CAN bus error. But
> > in case of an error situation the interrupt load would be very high (e.g.
> > short circuit of the CAN).
> >
> That's what berr-reporting does, right? Considering that when the bus is
> flooded with errors, things are in a pretty bad shape anyway, I think it's
> not really going to contribute much to the over-all mess to just leave the
> error interrupts on all the time. It's far worse if the user doesn't get
> the correct error state.
> 
> Anyway, defensive measures can be taken. When the bus has reached
> error-passive, the driver is not going to need those interrupts any more
> so it could turn off the interrupts until the bus goes to bus-off or back
> down to warning or active; except when berr-reporting is enabled.

Would you mind trying out the patch series posted a few days ago here:

http://article.gmane.org/gmane.linux.can/6654

It applies to the flexcan-next branch of
git://gitorious.org/linux-can/linux-can-next.git
(base commit should be 907aa2d61697035a921cad6375c0d546b1d18af6 if HEAD fails).

I think it solves your problem.

Best regards,

-- 
David Jander
Protonic Holland.