Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220909145942.844102-1-horatiu.vultur@microchip.com> <20220920120642.690340-1-michael@walle.cc>
In-Reply-To: <20220920120642.690340-1-michael@walle.cc>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Tue, 20 Sep 2022 14:28:44 +0200
Message-ID: <CACRpkdb70zawWDSxUM=hJYkOEbG5a5guZWBytqUmRG2FZLiXsQ@mail.gmail.com>
Subject: Re: [PATCH v3] pinctrl: ocelot: Fix interrupt controller
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
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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