netdev - Re: status of rate adaptation

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: <Y2/E4FQzlw+T+6c/@lunn.ch>
Date:   Sat, 12 Nov 2022 17:08:00 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Sean Anderson <sean.anderson@...o.com>,
        Tim Harvey <tharvey@...eworks.com>,
        netdev <netdev@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: status of rate adaptation

> As to LEVEL_LOW vs EDGE_FALLING, I suppose the only real difference is
> if the interrupt line is shared with other peripherals?

It pretty much always is, on the PHY side. The PHY is an interrupt
controller, with lots of different interrupt sources within the PHY
coming together to trigger one external interrupt. It is unlikely to
produce another edge if the hardware has another interrupt source
trigger an interrupt while the interrupt handler is running. With a
level interrupt, the interrupt handler will exit, the interrupt will
get enabled in the parent interrupt controller, and immediately fire
again.

I have seen some boards using edge, but that is only because the
interrupt controller does not support level. They mostly get away with
it because generally PHYs are slow things, interrupts tend to be few
and infrequency and the race window is small.

	Andrew