From: Torin Cooper-Bennun <torin@maxiluxsystems.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org
Subject: Re: [PATCH RFC can-next 0/3] m_can: support device-specific interrupt handling
Date: Fri, 14 May 2021 17:46:37 +0100 [thread overview]
Message-ID: <20210514164637.ikdluiachvoidmpy@bigthink> (raw)
In-Reply-To: <20210514145556.utpdscudwcidmmcz@pengutronix.de>
[-- 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 --]
next prev parent reply other threads:[~2021-05-14 16:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-14 12:19 [PATCH RFC can-next 0/3] m_can: support device-specific interrupt handling Torin Cooper-Bennun
2021-05-14 12:19 ` [PATCH RFC can-next 1/3] can: m_can: add handle_dev_interrupts callback to m_can_ops Torin Cooper-Bennun
2021-05-14 12:26 ` Marc Kleine-Budde
2021-05-14 13:21 ` Torin Cooper-Bennun
2021-05-14 14:16 ` Marc Kleine-Budde
2021-05-14 12:19 ` [PATCH RFC can-next 2/3] can: m_can: m_can_isr(): handle device-specific interrupts Torin Cooper-Bennun
2021-05-14 12:19 ` [PATCH RFC can-next 3/3] can: tcan4x5x: add handle_dev_interrupts callback to ops Torin Cooper-Bennun
2021-05-14 14:10 ` Marc Kleine-Budde
2021-05-14 14:51 ` Torin Cooper-Bennun
2021-05-14 15:15 ` Marc Kleine-Budde
2021-05-14 16:27 ` Torin Cooper-Bennun
2021-05-14 12:34 ` [PATCH RFC can-next 0/3] m_can: support device-specific interrupt handling Marc Kleine-Budde
2021-05-14 13:10 ` Torin Cooper-Bennun
2021-05-14 14:12 ` Marc Kleine-Budde
2021-05-14 14:44 ` Torin Cooper-Bennun
2021-05-14 14:55 ` Marc Kleine-Budde
2021-05-14 16:46 ` Torin Cooper-Bennun [this message]
2021-05-14 14:54 ` Torin Cooper-Bennun
2021-05-14 15:21 ` Marc Kleine-Budde
2021-05-14 16:44 ` Torin Cooper-Bennun
2021-05-14 17:13 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210514164637.ikdluiachvoidmpy@bigthink \
--to=torin@maxiluxsystems.com \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.