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: 1506 bytes --]

On Fri, May 14, 2021 at 02:34:17PM +0200, Marc Kleine-Budde wrote:
> On 14.05.2021 13:19:43, Torin Cooper-Bennun wrote:
> > Using the TCAN4550, I've had occasions where the m_can driver has fallen
> > over with the "nobody cared" message -- the ISR has returned IRQ_NONE
> > upon "99,900 of the previous 100,000 interrupts" (see
> > kernel/irq/spurious.c, __report_bad_irq()).
> > 
> > While such high numbers certainly indicate some kind of fault,
> > presently, device-specific interrupts are totally ignored -- it may be
> > that such a fault can be handled with a device-specific action.
> 
> Do you know why the tcan4x5x specific interrupts are enabled in the
> first place? If no-one is handling them, just mask/disable/etc then....

The TCAN4550 has interrupts that cannot be disabled or masked, including
those for faults involving SPI, power, and transceiver issues (e.g. CAN
stuck dominant).

> 
> > Comments are welcome. One thing right off the bat: I'm not sure whether
> > the new callback should be added alongside clear_interrupts, or if it
> > should replace it.
> 
> I don't see why we need two callbacks from the generic interrupt
> handler, one should be enough.

Fair enough, and it makes sense to always clear the device-specific
interrupts when handling them anyway.

tcan4x5x needs some cleanup re interrupt init/handling/clearing anyway,
so I'll incorporate that next time!

Regards,

Torin Cooper-Bennun
Software Engineer | maxiluxsystems.com


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