On Tue, 2 Mar 2021 10:01:09 +0100, Ard Biesheuvel wrote:
> [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using
> SIMD in kernel mode could reduce complexity and improve performance, but we
> need to decide whether we can do this, and how much softirq processing
> late
On Tue, 6 Oct 2020 11:33:26 -0500, Jeremy Linton wrote:
> The AES code uses a 'br x7' as part of a function called by
> a macro. That branch needs a bti_j as a target. This results
> in a panic as seen below. Using x16 (or x17) with an indirect
> branch keeps the target bti_c.
>
> Bad mode in Sy
On Tue, Oct 06, 2020 at 11:43:14AM +0100, Dave P Martin wrote:
> On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> > On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > > On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > > &
On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P 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
> > > a macro. That branch needs a bti_j
On Wed, Oct 02, 2019 at 08:09:18PM +0200, Ard Biesheuvel wrote:
> On Wed, 2 Oct 2019 at 19:23, Catalin Marinas wrote:
> > On Wed, Oct 02, 2019 at 09:47:41AM -0700, Nick Desaulniers wrote:
> > > I'm running into some inconsistencies between how clang parses target
> >
On Wed, Oct 02, 2019 at 09:47:41AM -0700, Nick Desaulniers wrote:
> On Wed, Oct 2, 2019 at 12:55 AM Ard Biesheuvel
> wrote:
> >
> > Now that the Clang compiler has taken it upon itself to police the
> > compiler command line, and reject combinations for arguments it views
> > as incompatible, the
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 feature bit and wire it up to th
: fix for big endian
> crypto: arm/aes-ce - fix for big endian
The changes look fine to me but I can't claim I fully understand these
algorithms. FWIW:
Acked-by: Catalin Marinas
(Will may pick them up for 4.9-rcX)
--
To unsubscribe from this list: send the line "unsubscribe li
On Thu, May 05, 2016 at 06:36:04PM +0300, Horia Geantă wrote:
> This will allow device drivers to consistently use io{read,write}XXbe
> also for 64-bit accesses.
>
> Signed-off-by: Alex Porosanu
> Signed-off-by: Horia Geantă
Acked-by: Catalin Marinas
--
To unsubscribe from this
On Wed, May 20, 2015 at 02:04:02PM +0200, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 06:52:03 Suravee Suthikulanit wrote:
> > On 5/20/2015 5:01 AM, Catalin Marinas wrote:
> > > On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
> >
On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
> +static inline bool acpi_dma_is_supported(struct acpi_device *adev)
> +{
> + /**
> + * Currently, we mainly support _CCA=1 (i.e. is_coherent=1)
> + * This should be equivalent to specifyig dma-coherent for
> +
On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
> > On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
> > > On Friday, May 15, 2015 04:23:11 PM Suravee S
On Wed, Oct 22, 2014 at 05:31:32PM +0100, Ard Biesheuvel wrote:
> On 22 October 2014 18:25, Catalin Marinas wrote:
> > On Wed, Oct 22, 2014 at 08:15:32AM +0100, Ard Biesheuvel wrote:
> >> This patch implements the AES key schedule generation using ARMv8
> >> Crypto In
On Wed, Oct 22, 2014 at 08:15:32AM +0100, Ard Biesheuvel wrote:
> This patch implements the AES key schedule generation using ARMv8
> Crypto Instructions. It replaces the table based C implementation
> in aes_generic.ko, which means we can drop the dependency on that
> module.
I don't really under
On Thu, May 15, 2014 at 11:10:20PM +0100, Ard Biesheuvel wrote:
> On 15 May 2014 14:47, Catalin Marinas wrote:
> > For the time being I would drop the last 4 patches. We can revisit them
> > for the next kernel version.
>
> Agreed.
>
> Should I send an updated p
On 15 May 2014, at 22:35, Ard Biesheuvel wrote:
> On 15 May 2014 10:24, Catalin Marinas wrote:
>> On Wed, May 14, 2014 at 07:17:29PM +0100, Ard Biesheuvel wrote:
>>> +static u8 const *sha1_do_update(struct shash_desc *desc, const u8 *data,
>>> +
On Wed, May 14, 2014 at 07:17:29PM +0100, Ard Biesheuvel wrote:
> The Crypto Extensions based SHA1 implementation uses the NEON register file,
> and hence runs with preemption disabled. This patch adds a TIF_NEED_RESCHED
> check to its inner loop so we at least give up the CPU voluntarily when we
>
On Wed, May 14, 2014 at 02:29:05AM +0100, Herbert Xu wrote:
> On Fri, May 09, 2014 at 08:37:58AM +0200, Ard Biesheuvel wrote:
> >
> > @Herbert, Jussi: care to share your opinion on the SHAx, GHASH and AES
> > patches above? Herbert has already acked the ccm patch, but Catalin is
> > requesting for
On 8 May 2014, at 12:22, Ard Biesheuvel wrote:
> On 7 May 2014 16:45, Catalin Marinas wrote:
>> On Thu, May 01, 2014 at 04:49:32PM +0100, Ard Biesheuvel wrote:
>>> This is a repost of the arm64 crypto patches that I have posted to the LAKML
>>> over the past months.
On Thu, May 01, 2014 at 04:49:32PM +0100, Ard Biesheuvel wrote:
> This is a repost of the arm64 crypto patches that I have posted to the LAKML
> over the past months. They have now been verified on actual hardware
> (Cortex-A57) so if there are no remaining issues I would like to propose them
> for
On Thu, May 01, 2014 at 04:49:36PM +0100, Ard Biesheuvel wrote:
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index 7a900142dbc8..05e1b24aca4c 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -41,6 +41,17 @@ struct fpsi
On Tue, May 06, 2014 at 05:25:14PM +0100, Ard Biesheuvel wrote:
> On 6 May 2014 18:08, Catalin Marinas wrote:
> > On Thu, May 01, 2014 at 04:49:35PM +0100, Ard Biesheuvel wrote:
> >> @@ -153,12 +252,11 @@ static int fpsimd_cpu_pm_notifier(struct
> &g
On Thu, May 01, 2014 at 04:49:35PM +0100, Ard Biesheuvel wrote:
> @@ -153,12 +252,11 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block
> *self,
> {
> switch (cmd) {
> case CPU_PM_ENTER:
> - if (current->mm)
> + if (current->mm && !test_thread_f
On Tue, May 06, 2014 at 04:12:55PM +0100, Catalin Marinas wrote:
> On Tue, May 06, 2014 at 03:48:08PM +0100, Ard Biesheuvel wrote:
> > On 6 May 2014 16:43, Catalin Marinas wrote:
> > > On Thu, May 01, 2014 at 04:49:34PM +0100, Ard Biesheuvel wrote:
> > >> diff --git
On Tue, May 06, 2014 at 03:34:23PM +0100, Ard Biesheuvel wrote:
> On 6 May 2014 16:31, Catalin Marinas wrote:
> > On Thu, May 01, 2014 at 04:49:33PM +0100, Ard Biesheuvel wrote:
> >> Switch the default unaligned access method to 'hardware implemented'
> >>
On Tue, May 06, 2014 at 03:48:08PM +0100, Ard Biesheuvel wrote:
> On 6 May 2014 16:43, Catalin Marinas wrote:
> > On Thu, May 01, 2014 at 04:49:34PM +0100, Ard Biesheuvel wrote:
> >> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> >> index 4aef42
On Thu, May 01, 2014 at 04:49:34PM +0100, Ard Biesheuvel wrote:
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 4aef42a04bdc..86ac6a9bc86a 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -87,6 +87,39 @@ void fpsimd_flush_thread(void)
On Thu, May 01, 2014 at 04:49:33PM +0100, Ard Biesheuvel wrote:
> Switch the default unaligned access method to 'hardware implemented'
> if HAVE_EFFICIENT_UNALIGNED_ACCESS is set.
>
> Signed-off-by: Ard Biesheuvel
> Acked-by: Arnd Bergmann
> ---
> include/asm-generic/unaligned.h | 21 ++
On Wed, 2009-09-16 at 19:58 +0200, Sebastian Andrzej Siewior wrote:
> As reported by Frans Pop the new global macro W on ARM which is included
> via
> |arch/arm/include/asm/uaccess.h:20
> |include/linux/uaccess.h:5
> |include/linux/crypto.h:26
> |crypto/cast6.c:23
>
> leads to a build error becaus
29 matches
Mail list logo
