netdev - Re: [PATCH] net: phy: realtek: Dummy IRQ calls for RTL8366RB

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: <CACRpkdaisrc1h-9Pa70bswV0K8PPj=+YGNRBZXq5cqvRNirATw@mail.gmail.com>
Date:   Sun, 24 Feb 2019 00:57:04 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH] net: phy: realtek: Dummy IRQ calls for RTL8366RB

On Sat, Feb 23, 2019 at 4:17 PM Andrew Lunn <andrew@...n.ch> wrote:
> On Sat, Feb 23, 2019 at 03:36:39AM +0100, Linus Walleij wrote:

> > This fixes a regression introduced by
> > commit 0d2e778e38e0ddffab4bb2b0e9ed2ad5165c4bf7
> > "net: phy: replace PHY_HAS_INTERRUPT with a check for
> > config_intr and ack_interrupt".
> >
> > This assumes that a PHY cannot trigger interrupt unless
> > it has .config_intr() or .ack_interrupt() implemented.
> > A later patch makes the code assume both need to be
> > implemented for interrupts to be present.
> >
> > But this PHY (which is inside a DSA) will happily
> > fire interrupts without either callback.
>
> Hi Linus
>
> Can you disable these interrupts?
>
> If you have dummy implementations, what is clearing the interrupt?

They are handled by the irqchip mask/unmask inside
the RTL8366RB, see:
drivers/net/dsa/rtl8366rb.c

So as soon as the phy core request the threaded IRQ
the irqchip will deal with this business on its own.

How exactly the RTL8366RB IRQ machine looks inside
I doubt even Realtek knows themselves, but from
my experiements, they seem all edge triggered,
and the irq will be raised every time an edge occurse
(such as inserting or removing the cable). The "ACK"
happens in hardware when we read the status register
in the nested interrupt handler in rtl8366rb_irq() so no
further registers need to be accessed.

Yours,
Linus Walleij