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

On Fri, May 14, 2021 at 04:55:56PM +0200, Marc Kleine-Budde wrote:
> On 14.05.2021 15:44:34, Torin Cooper-Bennun wrote:
> > On Fri, May 14, 2021 at 04:12:37PM +0200, Marc Kleine-Budde wrote:
> > > > 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?
> > 
> > In theory, for any of these, clearing the register should be sufficient
> > for the interrupt pin to go inactive... emphasis on "in theory".
> 
> Ok, but as you noticed in your patch, if no IRQ is pending in M_CAN_IR,
> the main driver doesn't call the tcan4x5x handler.
> 
> So the IRQ stays active, the IRQ handler is repeatedly called and
> returns IRQ_NONE. Then you get the nobody cared warning.

I miscommunicated a bit there. I was just referring to the fact that
some of these interrupts are really broken, e.g. re-asserting for no
reason, despite what the datasheet says, yada yada.

--
Regards,

Torin Cooper-Bennun
Software Engineer | maxiluxsystems.com


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