linux-kernel - Re: [PATCH v3] pinctrl: ocelot: Fix interrupt controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdb70zawWDSxUM=hJYkOEbG5a5guZWBytqUmRG2FZLiXsQ@mail.gmail.com>
Date:   Tue, 20 Sep 2022 14:28:44 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Michael Walle <michael@...le.cc>
Cc:     horatiu.vultur@...rochip.com, UNGLinuxDriver@...rochip.com,
        andy.shevchenko@...il.com, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] pinctrl: ocelot: Fix interrupt controller

On Tue, Sep 20, 2022 at 2:06 PM Michael Walle <michael@...le.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