> (+ Andy)
Thanks! Applied to cryptogams, pinged openssl. Cheers.
Hi,
On 10/11/2019 7:21 PM, René van Dorst wrote:
>
> ...
>
> I also wonder if we can also replace the "li $x, -4" and "and $x" with
> "sll $x"
> combination on other places like [0], also on line 1169?
>
> Replace this on line 1169, works on my device.
>
> - li $in0,-4
> srl
Hi,
On 10/8/19 1:38 PM, Andy Polyakov wrote:
>>>
>>
>> Hi Ard,
>>
>> Is it also an option to include my mip32r2 optimized poly1305 version?
>>
>> Below the results which shows a good improvement over the Andy Polyakov
>> version.
>> I swap
Hi,
On 10/7/19 11:02 PM, René van Dorst wrote:
> Quoting Ard Biesheuvel :
>
>> This is a straight import of the OpenSSL/CRYPTOGAMS Poly1305
>> implementation
>> for MIPS authored by Andy Polyakov, and contributed by him to the OpenSSL
>> project.
Formally
> Looking at the generated code, I see references to __ARMEB__ and
__ILP32__.
> The former is probably a bug,
>>>
>>> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
>>
>> Indeed:
>>
>> $ aarch64-linux-gnu-gcc -dM -E - <<<"" |grep AARCH
>> #define __AARCH64_CMODEL_SMALL_
>>> (+ Andy)
>>>
>>> ...
Looking at the generated code, I see references to __ARMEB__ and
>>> __ILP32__.
The former is probably a bug,
>>
>> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
>
> Indeed:
>
> $ aarch64-linux-gnu-gcc -dM -E - <<<"" |grep AARCH
> #define _
> (+ Andy)
>
> ...
>>
>> Looking at the generated code, I see references to __ARMEB__ and
> __ILP32__.
>> The former is probably a bug,
Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__! Apparently I
simply went on assuming that it would be __ARMEB__/__ARMEL__ even in
64-bit case. As Ard
> This is a port of the ARMv7 implementation in arch/arm/crypto. For a
> Cortex-A57
> (r2p1), the performance numbers are listed below. In summary, 40% - 50%
> speedup
> where it counts, i.e., block sizes over 256 bytes with few updates.
Cool! Great! Just in case for reference. You compare gener
> This updates the SHA-512 NEON module with the faster and more
> versatile implementation from the OpenSSL project. It consists
> of both a NEON and a generic ASM version of the core SHA-512
> transform, where the NEON version reverts to the ASM version
> when invoked in non-process context.
>
>
arch/arm/crypto/sha256-core.S: Assembler messages:
arch/arm/crypto/sha256-core.S:1847: Error: invalid constant (efb0)
after fixup
This is caused by the fact that, when building the integer-only code
for an older architecture, the conditional compilation produces a
>> Could you share the error log please?
>
> OK, I spotted one issue with this code:
>
> arch/arm/crypto/sha256-core.S: Assembler messages:
> arch/arm/crypto/sha256-core.S:1847: Error: invalid constant (efb0)
> after fixup
>
> This is caused by the fact that, when building the integer-only c
Hi,
>>> Have you tested this code with the tcrypt.ko module?
>>
>> I have not, but I can look into it.
>>
>>> Did you talk to Andy about the license? I don't think this is
>>> permissible for the kernel as-is.
>>
>> Unless I have misunderstood something, the license at the Cryptogams
>> website in
12 matches
Mail list logo