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: <20221112004827.oy62fd7aah6alay2@skbuf>
Date:   Sat, 12 Nov 2022 02:48:27 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Sean Anderson <sean.anderson@...o.com>
Cc:     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

On Fri, Nov 11, 2022 at 05:38:12PM -0500, Sean Anderson wrote:
> > Something interesting is that when I configured the xmdio node with an
> > interrupt I ended up in a mode where 5g,2.5g and 1g all worked for at
> > least 1 test. There was something wrong with my interrupt
> > configuration (i'm not clear if the AQR113C's interrupt should be
> > IRQ_TYPE_LEVEL_LOW, IRQ_TYPE_EDGE_FALLING or something different).
> 
> NXP use IRQ_TYPE_LEVEL_HIGH on the LS1046ARDB.

Partly true, but mostly false. What is described in fsl-ls1046a-rdb.dts as:

	interrupts = <0 131 4>;

should really have been described as:

	interrupts-extended = <&extirq 0 IRQ_TYPE_LEVEL_LOW>;

There's a polarity inverter which inverts the signal by default,
changing what the GIC sees. The first description bypasses it.
So that's not what the problem is in Tim's case.

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