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: <Y4S4EfChuo0wmX2k@lunn.ch>
Date:   Mon, 28 Nov 2022 14:30:57 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Michael Walle <michael@...le.cc>
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

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.

    Andrew