On Sun, 13 Jul 2025 10:05:22 +0200, Luca Weiss wrote:
> Document various bits of the Milos SoC in the dt-bindings, which don't
> really need any other changes.
>
> Then we can add the dtsi for the Milos SoC and finally add a dts for
> the newly announced The Fairphone (Gen. 6) smartphone.
>
> Dep
o/sha512-ce-core.S | 2 +-
> arch/arm64/include/asm/assembler.h | 28 +++-
> arch/arm64/kernel/asm-offsets.c| 2 ++
> arch/arm64/kernel/fpsimd.c | 4 +--
> 8 files changed, 31 insertions(+), 15 deletions(-)
Acked-by: Will Deacon
Will
t version.
> + */
> + .irp
> n,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
> + wx\n.reqw\n
> + .endr
That's a pretty neat hack! I remember seeing code elsewhere which would
benefit from this, so might be worth a look at our other macros as I'm sure
I got annoyed by one the other day... ah yes, the SVE macros in fpsimdmacros.h
Acked-by: Will Deacon
Will
rch/arm64/include/asm/assembler.h | 70
> 1 file changed, 70 deletions(-)
Acked-by: Will Deacon
Will
On Thu, Feb 04, 2021 at 10:10:26PM +1100, Herbert Xu wrote:
> On Thu, Feb 04, 2021 at 09:29:16AM +0100, Ard Biesheuvel wrote:
> >
> > Half of the patches in this series conflict with
> >
> > 0df07d8117c3 crypto: arm64/sha - add missing module aliases
> >
> > in the cryptodev tree, so that won't w
On Wed, Feb 03, 2021 at 09:31:31PM +, Will Deacon wrote:
> On Wed, 3 Feb 2021 12:36:17 +0100, Ard Biesheuvel wrote:
> > Given how kernel mode NEON code disables preemption (to ensure that the
> > FP/SIMD register state is protected without having to context switch it),
> >
On Wed, 3 Feb 2021 12:36:17 +0100, Ard Biesheuvel wrote:
> Given how kernel mode NEON code disables preemption (to ensure that the
> FP/SIMD register state is protected without having to context switch it),
> we need to take care not to let those algorithms operate on unbounded
> input data, or we
On Thu, Jan 28, 2021 at 08:24:01PM +, Will Deacon wrote:
> On Thu, Jan 28, 2021 at 02:06:17PM +0100, Ard Biesheuvel wrote:
> > Add a macro cond_yield that branches to a specified label when called if
> > the TIF_NEED_RESCHED flag is set and decreasing the preempt count would
&g
On Thu, Jan 28, 2021 at 02:06:17PM +0100, Ard Biesheuvel wrote:
> Add a macro cond_yield that branches to a specified label when called if
> the TIF_NEED_RESCHED flag is set and decreasing the preempt count would
> make the task preemptible again, resulting in a schedule to occur. This
> can be use
On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave Martin wrote:
> On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > The AES code uses a 'br x7' as part of a function called by
> > &g
99: bl __xts_crypt8
> + bl \do8
>
> ldp q16, q17, [sp, #.Lframe_local_offset]
> ldp q18, q19, [sp, #.Lframe_local_offset + 32]
Acked-by: Will Deacon
Catalin -- can you pick this for 5.9 please?
Will
return PTR_ERR_OR_ZERO(ctx->hash);
> }
>
> static void essiv_cbc_exit_tfm(struct crypto_skcipher *tfm)
Acked-by: Will Deacon
Assuming this will go via Herbert.
Will
[+Marc]
On Mon, Jul 01, 2019 at 09:28:06AM +0100, Will Deacon wrote:
> [Note: this was in my spam folder]
>
> On Fri, Jun 28, 2019 at 06:05:10PM +, Saidi, Ali wrote:
> > On 6/7/19, 7:59 AM, " Ali Saidi" wrote:
> > On 6/5/19, 7:20 AM, "Will Deacon
[Note: this was in my spam folder]
On Fri, Jun 28, 2019 at 06:05:10PM +, Saidi, Ali wrote:
> On 6/7/19, 7:59 AM, " Ali Saidi" wrote:
> On 6/5/19, 7:20 AM, "Will Deacon" wrote:
> On Tue, Jun 04, 2019 at 08:30:57PM +, Ali Saidi wrote:
>
On Tue, Jun 04, 2019 at 08:30:57PM +, Ali Saidi wrote:
> AWS Graviton based systems provide an Arm SMC call in the vendor defined
> hypervisor region to read random numbers from a HW TRNG and return them to the
> guest.
>
> We've observed slower guest boot and especially reboot times due to l
.
Why is it annoying? You still end up with a working kernel.
> It'd nicer if we can check assembler first and opt-in feature
> visibility in Kconfig.
>
> Cc: Masahiro Yamada
> Cc: Will Deacon
> Cc: Marc Zyngier
> Cc: Ard Biesheuvel
> Signed-off-by: Vladimir Mur
On Tue, Sep 04, 2018 at 11:18:55AM +0800, Herbert Xu wrote:
> On Tue, Aug 28, 2018 at 08:43:35PM +0200, Ard Biesheuvel wrote:
> > On 28 August 2018 at 19:01, Will Deacon wrote:
> > > On Mon, Aug 27, 2018 at 01:02:43PM +0200, Ard Biesheuvel wrote:
> > >> Add a CRC32
.h | 3 ++-
> arch/arm64/kernel/cpufeature.c | 9 +
> 2 files changed, 11 insertions(+), 1 deletion(-)
Acked-by: Will Deacon
With the minor caveat below...
> diff --git a/arch/arm64/include/asm/cpucaps.h
> b/arch/arm64/include/asm/cpucaps.h
> index ae1f70450fb2..9932a
On Mon, Aug 20, 2018 at 03:40:32PM -0700, 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
Does still this work correctly fo
On Tue, Jul 31, 2018 at 09:22:52AM +0200, Ard Biesheuvel wrote:
> (+ Catalin, Will)
>
> On 27 July 2018 at 14:59, Ard Biesheuvel wrote:
> > Calling pmull_gcm_encrypt_block() requires kernel_neon_begin() and
> > kernel_neon_end() to be used since the routine touches the NEON
> > register file. Add
On Fri, Jan 26, 2018 at 12:05:42PM +0300, Yury Norov wrote:
> On Wed, Jan 24, 2018 at 10:22:13AM +0000, Will Deacon wrote:
> > On Wed, Jan 24, 2018 at 12:05:16PM +0300, Yury Norov wrote:
> > > This series adds API for 128-bit memory IO access and enables it for
> > >
On Wed, Jan 24, 2018 at 12:05:16PM +0300, Yury Norov wrote:
> This series adds API for 128-bit memory IO access and enables it for ARM64.
> The original motivation for 128-bit API came from new Cavium network device
> driver. The hardware requires 128-bit access to make things work. See
> descripti
On Fri, Jan 27, 2017 at 10:43:16AM +, Ard Biesheuvel wrote:
> On 27 January 2017 at 10:40, Matthias Brugger wrote:
> > Older compilers may not be able to detect the crc32 extended cpu type.
>
> What do you mean 'detect'? Could you describe the failure in more detail
> please?
>
> > Anyway on
On Mon, Nov 28, 2016 at 02:17:34PM +0100, Ard Biesheuvel wrote:
> On 28 November 2016 at 13:05, Will Deacon wrote:
> > On Sun, Nov 20, 2016 at 11:42:01AM +, Ard Biesheuvel wrote:
> >> This integrates both the accelerated scalar and the NEON implementations
> >> of
On Sun, Nov 20, 2016 at 11:42:01AM +, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
>
Hi Ard,
On Sat, Nov 12, 2016 at 01:32:33PM +0100, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
>
On Fri, Nov 11, 2016 at 09:51:13PM +0800, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
>
On Wed, Oct 19, 2016 at 09:49:46AM +0100, Ard Biesheuvel wrote:
> On 19 October 2016 at 09:46, Will Deacon wrote:
> > On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> >> I was planning merging these for 4.10. But I'm fine with them
> >> going through
On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> > On 18 October 2016 at 12:49, Catalin Marinas
> > wrote:
> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> > >> As it turns out, none of the accel
On Fri, Feb 12, 2016 at 06:00:01PM +0100, Ard Biesheuvel wrote:
> On 12 February 2016 at 16:47, Jeremy Linton wrote:
> > ECB modes don't use an initialization vector. The kernel
> > /proc/crypto interface doesn't reflect this properly.
> >
> > Signed-off-by: Jeremy Linton
>
> Thanks for spotting
On Fri, Aug 28, 2015 at 12:49:47PM +0100, Horia Geantă wrote:
> This will allow device drivers to consistently use io{read,write}XXbe
> macros also for 64-bit accesses.
>
> Signed-off-by: Alex Porosanu
> Signed-off-by: Horia Geantă
> ---
> arch/arm64/include/asm/io.h | 4 +++-
> 1 file changed,
On Fri, Jun 26, 2015 at 11:09:44AM +0100, Herbert Xu wrote:
> On Fri, Jun 26, 2015 at 11:08:05AM +0100, Will Deacon wrote:
> > Hi all,
> >
> > arm64 allmodconfig fails to build with mainline due to the following:
> >
> >
> > In file included fr
Hi all,
arm64 allmodconfig fails to build with mainline due to the following:
In file included from include/acpi/platform/aclinux.h:74:0,
from include/acpi/platform/acenv.h:173,
from include/acpi/acpi.h:56,
from include/linux/acpi.h:37,
On Tue, Mar 17, 2015 at 06:05:13PM +, Ard Biesheuvel wrote:
> This changes the AES core transform implementations to issue aese/aesmc
> (and aesd/aesimc) in pairs. This enables a micro-architectural optimization
> in recent Cortex-A5x cores that improves performance by 50-90%.
>
> Measured per
On Thu, Feb 19, 2015 at 05:25:16PM +, Ard Biesheuvel wrote:
> This patch increases the interleave factor for parallel AES modes
> to 4x. This improves performance on Cortex-A57 by ~35%. This is
> due to the 3-cycle latency of AES instructions on the A57's
> relatively deep pipeline (compared to
patch after discussion with Russell). There are cores out there that
don't predict mov pc, lr at all (let alone do anything with the return
stack).
> > discussing this with Will Deacon over the last couple of days, who has
> > also been talking to the hardware people in ARM,
Hi Ard,
On Thu, Oct 03, 2013 at 10:59:23PM +0100, Ard Biesheuvel wrote:
> Note to reviewers:
> Reviewing the file aesbs-core.S may be a bit overwhelming, so if there are any
> questions or concerns, please refer the file bsaes-armv7.pl which can be found
> at the link below. This is the original P
37 matches
Mail list logo
