Re: [PATCH RFC can-next 0/3] m_can: support device-specific interrupt handling

[Torin Cooper-Bennun <torin@maxiluxsystems.com>]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Fri, May 14, 2021 at 05:21:31PM +0200, Marc Kleine-Budde wrote:
> On 14.05.2021 15:54:30, Torin Cooper-Bennun wrote:
> > On Fri, May 14, 2021 at 04:12:37PM +0200, Marc Kleine-Budde wrote:
> > > Ah, ok. Do they need any handling/acknowledge? You only read TCAN4X5X_INT_FLAGS, are
> > > those clear-or-read?
> > 
> > An extra note on this... most of the faults worth responding to here are
> > serious enough that the interface should just be shut down, or at least,
> > the device will need to be init'd again. 
> > 
> > I'm surprised no handling was implemented in the first place -
> 
> At least you should write a warning message that you (as a developer)
> and your users get noticed when these error hits.
> 
> > makes it very difficult to debug problems when you're prototyping new
> > kit. The driver is written as though these interrupts are meaningless!
> 
> Proper error handling is not trivial....and from my experience, in most
> cases the documentation of those kinds of errors and how to recover is
> quite sparse, I haven't looked deep into the tcan4x5x docs though.

I guess I should give credit where it's due, in that the driver works
fine without full error handling for the vast majority of cases. It may
just be that the application I'm working on is more sensitive to faults.

The docs are fairly sparse on error handling from a programmer's
perspective, yes. I've learned more from experience with this chip than
from the datasheet!

--
Regards,

Torin Cooper-Bennun
Software Engineer | maxiluxsystems.com


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]