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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux