Am 2022-09-20 14:28, schrieb Linus Walleij:
On Tue, Sep 20, 2022 at 2:06 PM Michael Walle <michael@xxxxxxxx> 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.
Common but wrong? Except in the error case, /proc/interrupts
was always reliable on our boards :)
So I assume these are wire-OR, i.e. exploiting open drain with
a pull-up resistor.
Yes, the usual shared line interrupts.
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)?
Thanks, I'll check it.
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.
I've checked with a scope, the levels and edges look good.
A third problem would be that the line need time to rise.
But that should be uncommon.
I haven't looked at the code of this patch, but obiously it
is emulating the level triggered behavior with just a pin change
interrupt. There might also be something wrong there, too.
-michael
