Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 4 Oct 2019 15:46:44 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc:     linux-crypto@vger.kernel.org,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Miller <davem@davemloft.net>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Samuel Neves <sneves@dei.uc.pt>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Eric Biggers <ebiggers@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Martin Willi <martin@strongswan.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        =?utf-8?B?UmVuw6k=?= van Dorst <opensource@vdorst.com>
Subject: Re: [PATCH v2 05/20] crypto: mips/chacha - import accelerated 32r2
 code from Zinc
Message-ID: <20191004134644.GE112631@zx2c4.com>
References: <20191002141713.31189-1-ard.biesheuvel@linaro.org>
 <20191002141713.31189-6-ard.biesheuvel@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20191002141713.31189-6-ard.biesheuvel@linaro.org>
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 02, 2019 at 04:16:58PM +0200, Ard Biesheuvel wrote:
> This integrates the accelerated MIPS 32r2 implementation of ChaCha
> into both the API and library interfaces of the kernel crypto stack.
> 
> The significance of this is that, in addition to becoming available
> as an accelerated library implementation, it can also be used by
> existing crypto API code such as Adiantum (for block encryption on
> ultra low performance cores) or IPsec using chacha20poly1305. These
> are use cases that have already opted into using the abstract crypto
> API. In order to support Adiantum, the core assembler routine has
> been adapted to take the round count as a function argument rather
> than hardcoding it to 20.

Could you resubmit this with first my original commit and then with your
changes on top? I'd like to see and be able to review exactly what's
changed. If I recall correctly, René and I were really starved for
registers and tried pretty hard to avoid spilling to the stack, so I'm
interested to learn how you crammed a bit more sauce in there.

I also wonder if maybe it'd be better to just leave this as is with 20
rounds, which it was previously optimized for, and just not do
accelerated Adiantum for MIPS. Android has long since given up on the
ISA entirely.