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: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".

> > > > 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.

Sounds good!

--
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