netdev - 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 PHC
Open Source and information security mailing list archives

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

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

Date:   Fri, 25 Nov 2022 15:44:08 +0100
From:   Michael Walle <michael@...le.cc>
To:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>
Cc:     Horatiu Vultur <horatiu.vultur@...rochip.com>,
        netdev@...r.kernel.org, Xu Liang <lxu@...linear.com>
Subject: GPY215 PHY interrupt issue

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. 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? The only
one I can think of is to disable the interrupts for the GPY215
altogether depending on the firmware version. For now, I haven't
described the interrupt line in the device tree. But that cannot be
the solution here ;)

If anyone is interested in the scope screenshots:
https://walle.cc/d10/gpy215_fw7_71_link_up_mdio.png
https://walle.cc/d10/gpy215_fw7_118_link_down_mdio1.png
https://walle.cc/d10/gpy215_fw7_71_link_down_mdio1.png
https://walle.cc/d10/gpy215c_fw8_111_link_down1.png

Red is MDIO, yellow is PHY_INT#, in all cases the second
transaction is the read interrupt status of the PHY which
asserts the interrupt line. Please note, that this is a
shared interrupt line. The first link shows the correct
behavior.

-michael