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:
signature.asc
Description: PGP signature
