linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Michael Walle <michael@walle.cc>
Cc: horatiu.vultur@microchip.com, UNGLinuxDriver@microchip.com,
	andy.shevchenko@gmail.com, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] pinctrl: ocelot: Fix interrupt controller
Date: Tue, 20 Sep 2022 14:28:44 +0200	[thread overview]
Message-ID: <CACRpkdb70zawWDSxUM=hJYkOEbG5a5guZWBytqUmRG2FZLiXsQ@mail.gmail.com> (raw)
In-Reply-To: <20220920120642.690340-1-michael@walle.cc>

On Tue, Sep 20, 2022 at 2:06 PM Michael Walle <michael@walle.cc> wrote:

> Our board has a shared active low interrupt line, connected to a quad PHY
> LAN8814 and two GPY215 PHYs. I've gave this a try but it doesn't seem to
> work. It seems the interrupt fires multiple times. If I plug a cable in
> one of the LAN8814 ports, I see that the interrupt count in
> /proc/interrupts has increased by two. If I use a GPY215 port, I see about
> 40 interrupts firing.

A lot of interrupts firing is very typical for level IRQs.

So I assume these are wire-OR, i.e. exploiting open drain with
a pull-up resistor.

Just checking: since these drivers obviously must pass pass
IRQF_SHARED, have you also made sure that each driver also
will properly return IRQ_HANDLED if the interrupt was for them
(triggered by "their" hardware) but IRQ_NONE if the interrupt was
not for them (triggered by something else)?

The IRQ core relies on all drivers to do the right thing here.

Otherwise the IRQ will just re-fire until someone/something
manages to properly handle it and drive the line high again.

A typical case would be the LAN8814 driver having been probed
first, thus its IRQ handler will be visited first, and always returning
IRQ_HANDLED thereby "stealing" the irq from everyone else.

Another possible problem is if you don't have an external pull-up
resistor and you need some pin config to enable pull-up on the
SoC input line. This will generate a lot of IRQs.

A third problem would be that the line need time to rise.
But that should be uncommon.

Yours,
Linus Walleij

  reply	other threads:[~2022-09-20 12:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 14:59 [PATCH v3] pinctrl: ocelot: Fix interrupt controller Horatiu Vultur
2022-09-09 15:09 ` Andy Shevchenko
2022-09-15 11:33   ` Horatiu Vultur
2022-09-14 13:02 ` Linus Walleij
2022-09-15 11:22   ` Horatiu Vultur
2022-09-18 18:55     ` Linus Walleij
2022-09-20 12:06 ` Michael Walle
2022-09-20 12:28   ` Linus Walleij [this message]
2022-09-20 12:34     ` Michael Walle
2022-09-20 14:25       ` Michael Walle
2022-09-20 19:30   ` Horatiu Vultur
2022-10-06 11:43     ` Michael Walle
2022-10-07  9:49       ` Horatiu Vultur
2022-10-13  7:30         ` Michael Walle
2022-10-13 14:11           ` Horatiu Vultur

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='CACRpkdb70zawWDSxUM=hJYkOEbG5a5guZWBytqUmRG2FZLiXsQ@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).