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: <c69e1d1d897dd7500b59c49f0873e7dd@walle.cc>
Date:   Thu, 01 Dec 2022 11:24:35 +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-28 14:30, schrieb Andrew Lunn:
> On Mon, Nov 28, 2022 at 08:41:17AM +0100, Michael Walle wrote:
>> Am 2022-11-25 16:17, schrieb Andrew Lunn:
>> > Or even turn it into an input and see if you can read its
>> > state and poll it until it clears?
>> 
>> Btw, I don't think that's possible for shared interrupts. In
>> the worst case you'd poll while another device is asserting the
>> interrupt line.
> 
> Yes, i thought about that afterwards. You need a timeout of 2ms for
> your polling, and then assume its the other PHY. But it also seems
> pretty unlikely that both PHYs go down within 2ms of each other. Maybe
> if you are using a bond and the switch at the other end looses power,
> but for normal use cases, it seems unlikely. It is also a question of
> complexity vs gain. 802.3 says something like you have to wait 750ms
> before declaring link down, so adding a 2ms sleep is just a bit more
> noise.

There are also other PHYs connected to this interrupt line, esp.
the LAN8814 which might do PHY timestamping in the future. Therefore,
I'd prefer a solution which "unblocks" interrupt line.

That being said, I've developed a patchset which change the MDINT
to GPIO mode (which isn't that easy because you need to go through
a mailbox mechanism to write to the internal bus), just to notice
that the access is apparently blocked as long as the interrupt
line is low :( I suspect that somehow the complete internal
bus is stalled due to some event, after which also the interrupt
line is released. Maybe they can't release the interrupt line
exactly because of this, who knows.

So, switching the line to GPIO input doesn't help here, which also
means the interrupt line will be stuck the whole time. Back to your
other suggestion that we can somehow poll the line. Currently I'm
trying to exploit the fact that even a read is blocked. IOW, in the
interrupt handler, I just read an internal register and wait until
that read was successful. Should be rather easy and also circument
the question "is this interrupt I'm polling on from another PHY
of the same line".

-michael