v8-a+fp16, armv8-a+memtag, armv8-a+lse, but I'm not familiar with
the `+...` part of the target arch.
Either way, thanks for the patch:
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
Reported-by:
Link: https://github.com/ClangBuiltLinux/linux/issues/730
> ---
> crypto/Kcon
+
> - $(obj)/sha256.o: $(srctree)/lib/sha256.c FORCE
> + $(obj)/sha256.o: $(srctree)/lib/crypto/sha256.c FORCE
> $(call if_changed_rule,cc_o_c)
>
> + CFLAGS_sha256.o := -D__DISABLE_EXPORTS
> +
> LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z
> nodefaultlib
> targets += purgatory.ro
>
--
Thanks,
~Nick Desaulniers
uire
> GCC 4.6 and newer in the kernel so we can eliminate all of the
> versioning checks and just use the C version of umul_ppmm for all
> supported compilers.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/605
> Suggested-by: Nick Desaulniers
> Signed-of
On Mon, Aug 12, 2019 at 10:22 AM Ard Biesheuvel
wrote:
>
> On Mon, 12 Aug 2019 at 19:50, Nick Desaulniers
> wrote:
> >
> > On Sun, Aug 11, 2019 at 3:59 PM Ard Biesheuvel
> > wrote:
> > > diff --git a/crypto/Makefile b/crypto/Makefile
> > > index
ciate that.
Certainly getting SIMD working exactly how you want across compilers
can be tricky.
>
> Cc: Nick Desaulniers
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/Makefile | 9 ++-
> crypto/aegis128-neon-inner.c | 65
> crypto/aegis12
r to be used on arm64 systems that do not
> implement those instructions (which are not mandatory in the
> architecture), such as the Raspberry Pi 3.
>
> Cc: Nick Desaulniers
Thanks for the heads up, thoughts below:
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/Makefile
};
>
> -static void crypto_aegis_block_xor(union aegis_block *dst,
> +static __always_inline void crypto_aegis_block_xor(union aegis_block *dst,
`static inline` would be more concise and expand to the same
attribute, IIRC. Not sure if that's worth sending a v2. But for now,
thanks for the patch and:
Acked-by: Nick Desaulniers
--
Thanks,
~Nick Desaulniers
On Wed, Jul 3, 2019 at 11:52 AM Nick Desaulniers
wrote:
>
> On Wed, Jul 3, 2019 at 9:15 AM Eric Biggers wrote:
> > Sorry, I am still confused. Are you saying that something still needs to be
> > fixed in the kernel code, and if so, why? To reiterate, the byteshift_table
&g
wasn't able to find any documentation that said alignment must match
entity size, but if there's not a functional reason for them to differ
then it seems like LLD need not even support such a particularly
non-common case.
--
Thanks,
~Nick Desaulniers
On Mon, Jun 17, 2019 at 11:06 AM Nick Desaulniers
wrote:
> In fact, looking closer at that diff, the section in question
> previously had 32b alignment. Eric, was that change intentional? It
> seems funny to have a 32b entity size but a 16b alignment.
32B & 16B
--
Thanks,
~Nick Desaulniers
same entity size and same flags. "
So for us, LLD is NOT merging these sections due to differing
alignments, which is producing warnings when loading such kernel
modules that link against these object files.
--
Thanks,
~Nick Desaulniers
ns. (I'm beginning to think we should change the values of the
enum members so that things break when aliased as such. Unfortunately,
that would result in runtime bugs rather than strong type system based
compile time checks; but this warning from Clang helps).
Reviewed-by: Nick Desaulniers
>
DEV_TO_MEM = 2
>
> Signed-off-by: Nathan Chancellor
Deja vu!
These particular enums get mixed up ALL THE TIME. Thanks for fixing
probably every instance of this bug (via patches before this one).
Reviewed-by: Nick Desaulniers
> ---
> drivers/crypto/ux500/cryp/cryp_core.c | 4 ++--
On Thu, Oct 11, 2018 at 12:47 AM Gilad Ben-Yossef wrote:
>
> Hi Nick,
>
> On Thu, Oct 11, 2018 at 2:49 AM Nick Desaulniers
> wrote:
> >
> > $ grep -r set_cipher_config0 -n
> >
> > shows a healthy mix of DESC_DIRECTION_ENCRYPT_ENCRYPT,
&g
esc
> *pdesc,
> * @pdesc: pointer HW descriptor struct
> * @mode: Any one of the modes defined in [CC7x-DESC]
> */
> -static inline void set_cipher_config0(struct cc_hw_desc *pdesc,
> - enum drv_crypto_direction mode)
> +static inline void set_cipher_config0(struct cc_hw_desc *pdesc, int mode)
> {
> pdesc->word[4] |= FIELD_PREP(WORD4_CIPHER_CONF0, mode);
> }
> --
> 2.19.1
>
--
Thanks,
~Nick Desaulniers
On Mon, Sep 24, 2018 at 2:27 PM Gary R Hook wrote:
>
> On 09/24/2018 03:24 PM, Nick Desaulniers wrote:
> > On Mon, Sep 24, 2018 at 12:18 PM Gary R Hook wrote:
> >>
> >> On 09/24/2018 12:26 PM, Nathan Chancellor wrote:
> >>> Clang emits a warning about
: Error: no such instruction:
> `seqcnt .req w7'
> arch/arm64/kernel/vdso/gettimeofday.S:30: Error: no such instruction:
> `w_tmp .req w8'
> ...
>
> The only reason I bring this up is that it would be helpful to be able
> to recreate results. I figure I'm not set up for this.
>
> That said... please see my response to Nick.
--
Thanks,
~Nick Desaulniers
acpi_version.
>
> I'm not going to out and out object to this just yet.
Tentative array definitions need to have the correct length specified;
it should either be forward declared as the correct length, or as this
patch does, skip the forward declare and move up the definition.
Thank
ent by itself, but also works around a Clang issue,
> whose integrated assembler does not implement the GNU ARM asm syntax
> completely, and does not support the =literal notation for FP registers
> (more info at https://bugs.llvm.org/show_bug.cgi?id=38642)
>
> Cc: Nick Desaulniers
On Tue, Aug 21, 2018 at 11:19 AM Ard Biesheuvel
wrote:
>
> On 21 August 2018 at 20:04, Nick Desaulniers wrote:
> > On Tue, Aug 21, 2018 at 9:46 AM Ard Biesheuvel
> > wrote:
> >>
> >> Replace the literal load of the addend vector with a sequence that
> &g
On Tue, Aug 21, 2018 at 10:25 AM Robin Murphy wrote:
>
> On 21/08/18 18:00, Ard Biesheuvel wrote:
> > On 21 August 2018 at 18:50, Nick Desaulniers
> > wrote:
> >> On Tue, Aug 21, 2018 at 5:23 AM Ard Biesheuvel
> >> wrote:
> >>>
> >&g
arch64/programmer-friendly.s;h=6254c6476efdc848648b05068be0574e7addc85d;hb=HEAD#l11
They can help provide more context to future travelers.
>
> Cc: Nick Desaulniers
> Signed-off-by: Ard Biesheuvel
> ---
> arch/arm64/crypto/aes-modes.S | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
On Tue, Aug 21, 2018 at 5:23 AM Ard Biesheuvel
wrote:
>
> Hi Nick,
>
> On 21 August 2018 at 00:40, Nick Desaulniers wrote:
> > It seems that:
> > ldr q8, =0x300020001
> >
> > is a GNU as convience notation for:
> > ldr q8, .Lconstant
>
On Mon, Aug 20, 2018 at 3:41 PM Nick Desaulniers
wrote:
>
> It seems that:
> ldr q8, =0x300020001
>
> is a GNU as convience notation for:
> ldr q8, .Lconstant
> .Lconstant
> .word 0x0001
> .word 0x0002
> .word 0x0003
> .word 0x
>
ned-off-by: Nick Desaulniers
---
arch/arm64/crypto/aes-modes.S | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index 483a7130cf0e..9288c5b0eca2 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/
Checked for transcription errors, calling convention, and removal of
temporary locals. LGTM.
Reviewed-By: Nick Desaulniers
On Tue, Nov 21, 2017 at 5:40 AM, Ard Biesheuvel
wrote:
> Most crypto drivers involving kernel mode NEON take care to put the code
> that actually touches the NEON re
26 matches
Mail list logo
