netdev - Re: GPY215 PHY interrupt issue

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: <c0e09154ee5e62c677d798f68ca7e537@walle.cc>
Date:   Sun, 27 Nov 2022 20:01:59 +0100
From:   Michael Walle <michael@...le.cc>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        netdev@...r.kernel.org, Xu Liang <lxu@...linear.com>
Subject: Re: GPY215 PHY interrupt issue

Am 2022-11-25 16:17, schrieb Andrew Lunn:
> On Fri, Nov 25, 2022 at 03:44:08PM +0100, Michael Walle wrote:
>> Hi,
>> 
>> I've been debugging an issue with spurious interrupts and it turns out
>> the GYP215 (possibly also other MaxLinear PHYs) has a problem with the
>> link down interrupt. Although the datasheet mentions (and which common
>> sense) a read of the interrupt status register will deassert the
>> interrupt line, the PHY doesn't deassert it right away. There is a
>> variable delay between reading the status register and the deassertion
>> of the interrupt line. This only happens on a link down event. The
>> actual delay depends on the firmware revision and is also somehow
>> random. With FW 7.71 (on a GPY215B) I've meassured around 40us with
>> FW 7.118 (GPY215B) it's about 2ms.
> 
> So you get 2ms of interrupt storm?

Yes.

> Does the interrupt status bit clear
> immediately, or does that clear only once the interrupt line itself
> has cleared? I'm assuming it clears immediately, otherwise you would
> add a polling loop.

Yeah, the register clears after it's read (i.e. the second read returns
zero). And yes 2ms

>> It also varies from link down to
>> link down. The issue is also present in the new GPY215C revision.
>> MaxLinear confirmed the issue and is currently working on a firmware
>> fix. But it seems that the issue cannot really be resolved. At best,
>> the delay can be minimized. If there will be a fix, this is then
>> only for a GPY215C and a new firmware version.
>> 
>> Does anyone have an idea of a viable software workaround?
> 
> Looking at the datasheet for the GPY215, the interrupt line is also
> GPIO 14. Could you flip it into a GPIO, force it inactive, and sleep
> to 2ms? Or even turn it into an input and see if you can read its
> state and poll it until it clears?

Nice idea. Let me try that. First obstacle is that it doesn't seem
to be documented how to do that. The vendor PHY API has some
ALTSEL and gpio functions, though.

-michael