On Fri, 10 Aug 2018, Joe Perches wrote:
> On Fri, 2018-08-10 at 16:02 -0400, Nicolas Pitre wrote:
> > On Fri, 10 Aug 2018, Joe Perches wrote:
> >
> > > On Fri, 2018-08-10 at 14:12 -0500, Jeff Lien wrote:
> > > > This patch provides a performance improvement
On Fri, 10 Aug 2018, Jeff Lien wrote:
> This patch provides a performance improvement for the CRC16 calculations done
> in read/write
> workloads using the T10 Type 1/2/3 guard field. For example, today with
> sequential write
> workloads (one thread/CPU of IO) we consume 100% of the CPU becaus
On Fri, 10 Aug 2018, Joe Perches wrote:
> On Fri, 2018-08-10 at 14:12 -0500, Jeff Lien wrote:
> > This patch provides a performance improvement for the CRC16 calculations
> > done in read/write
> > workloads using the T10 Type 1/2/3 guard field. For example, today with
> > sequential write
> >
for the IoT
> domain, where every kilobyte counts.
>
> For this reason, this series refactors the way the various AES
> implementations are wired up, to allow the generic version in
> crypto/aes_generic.c to be omitted from the build entirely.
I'm not a cryptographer but I do agre
On Sun, 26 Mar 2017, Ard Biesheuvel wrote:
> [...]
> +static const u32 rco_tab[10] = { 1, 2, 4, 8, 16, 32, 64, 128, 27, 54 };
You could consider using u8 for this table. This is a tiny space saving
and normally it shouldn't make the runtime any slower on most
architectures.
Nicolas
On Tue, 1 Jul 2014, Will Deacon wrote:
> Hi Mans,
>
> On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
> > Russell King - ARM Linux writes:
> > > As you point out, "bx lr" /may/ be treated specially (I've actually been
> >
> > Most, if not all, Cortex-A cores do this according the
On Fri, 4 Oct 2013, Russell King - ARM Linux wrote:
> On Fri, Oct 04, 2013 at 08:41:35PM +0200, Ard Biesheuvel wrote:
> > On 4 October 2013 20:34, Nicolas Pitre wrote:
> > > On Fri, 4 Oct 2013, Will Deacon wrote:
> > [...]
> > >>
> > >> Why do yo
On Fri, 4 Oct 2013, Ard Biesheuvel wrote:
> On 4 October 2013 20:34, Nicolas Pitre wrote:
> > On Fri, 4 Oct 2013, Will Deacon wrote:
> [...]
> >>
> >> Why do you consider it unsuitable to ship the perl script with the kernel?
> >> Perl 5 is alre
On Fri, 4 Oct 2013, Russell King - ARM Linux wrote:
> Also, remember that the GPL says:
>
> "The source code for a work means the preferred form of the work for
> making modifications to it."
>
> So here's the question: is the assembly code the perferred form to make
> modifications? From what
On Fri, 4 Oct 2013, Will Deacon wrote:
> 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
On Fri, 20 Sep 2013, 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 to the link below. This is the original
> Perl
> script that gets called by OpenSSL's build system during their bu
On Mon, 21 Jan 2013, Matt Sealey wrote:
> The optimized assembler SHA1 code for ARM does not conform to Thumb2
> register usage requirements, so it cannot be built when the kernel is
> configured with THUMB2_KERNEL.
>
> Fix the FTBFS for now by preventing misconfigurations of the kernel.
>
> Sig
quot; SHA1 is simply not worth
> keeping around.
Indeed. The ARM code in the kernel is mine:
|commit c09f98271f685af349d3f0199360f1c0e85550e0
|Author: Nicolas Pitre
|Date: Fri Oct 28 15:26:40 2005 +0100
|
| [ARM] 2930/1: optimized sha1 implementation for ARM
|
|Patch from Nicolas
Sebastian Andrzej Siewior
> ---
> * Nicolas Pitre | 2009-08-02 10:14:57 [-0400]:
> >Please submit it with the sg as is.
>
> Okay, here it is. The change is really minimal: flush_dcache out,
> SG_MITER_FROM_SG & SG_MITER_TO_SG in. Those slipped in just before -rc5.
>
> Herbert: a
On Sat, 1 Aug 2009, Sebastian Andrzej Siewior wrote:
> * Nicolas Pitre | 2009-06-11 17:19:22 [-0400]:
>
> >I have no problem with you submitting it now. It is not complete yet
> >but what is there is plenty functional. However I'd prefer if you used
> >the API ba
On Thu, 11 Jun 2009, Nicolas Pitre wrote:
> On Thu, 11 Jun 2009, Sebastian Andrzej Siewior wrote:
>
> > * Nicolas Pitre | 2009-06-11 16:36:42 [-0400]:
> >
> > >> Adding a revision history is good thing... I could not find the ARM tree
> > >> but I'
On Thu, 11 Jun 2009, Russell King - ARM Linux wrote:
> For these interfaces, I am a strong believer in purpose-defined
> interfaces to caches and the like. If what we have doesn't provide
> what's required, we need to provide something else.
>
> So, the question is what are you trying to do with
On Thu, 11 Jun 2009, Sebastian Andrzej Siewior wrote:
> * Nicolas Pitre | 2009-06-11 16:36:42 [-0400]:
>
> >> Adding a revision history is good thing... I could not find the ARM tree
> >> but I've rebased this patch against the orion tree [0].
> >
> >Act
On Thu, 11 Jun 2009, Sebastian Andrzej Siewior wrote:
> * Nicolas Pitre | 2009-06-11 15:17:09 [-0400]:
>
> >This one is already merged in the Orion and ARM tree, with a minor fix
> >and device renamed to be more generic. The equivalent registration for
> >Kirkwood i
On Thu, 11 Jun 2009, arm-ker...@ml.breakpoint.cc wrote:
> From: Sebastian Andrzej Siewior
>
> use the new driver for the crypto engine
>
> Signed-off-by: Sebastian Andrzej Siewior
Since the crypto engine is part of the SOC, this is not a board specific
thing. Hence this should be initialize
On Thu, 11 Jun 2009, arm-ker...@ml.breakpoint.cc wrote:
> From: Sebastian Andrzej Siewior
>
> The security accelerator which can act as a puppet player for the crypto
> engine requires its commands in the sram. This patch adds support for the
> phys mapping and creates a platform device the actu
On Sun, 13 Nov 2005, Herbert Xu wrote:
> On Mon, Oct 24, 2005 at 05:56:06PM +0000, Nicolas Pitre wrote:
> >
> > The current code unconditionally copy the first block for every call to
> > sha1_update(). This can be avoided if there is no pending partial block.
> > Thi
22 matches
Mail list logo
