On 14.05.2021 14:10:49, Torin Cooper-Bennun wrote: > 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). Ah, ok. Do they need any handling/acknowledge? You only read TCAN4X5X_INT_FLAGS, are those clear-or-read? > > > 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. ACK - and return irqreturn_t. > tcan4x5x needs some cleanup re interrupt init/handling/clearing anyway, > so I'll incorporate that next time! Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
