Hi Thomas,
CC Nemoto-san (de-facto TX49XX maintainer)
On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
I have an
The first argument to WARN() is a condition and the messages is the
second argument is the string, so this WARN() will only display the
__func__ part of the message.
Fixes: ae832e329a8d ("crypto: keembay-ocs-hcu - Add HMAC support")
Signed-off-by: Dan Carpenter
---
drivers/crypto/keembay/keembay
In the resource virtualization unit (RVU) each of the PF and AF
(admin function) share a 64KB of reserved memory region for
communication. This patch initializes PF <=> AF mailbox IRQs,
registers handlers for processing these communication messages.
Signed-off-by: Suheil Chandran
Signed-off-by: L
Adds skeleton for the Marvell OcteonTX2 CPT physical function
driver which includes probe, PCI specific initialization and
hardware register defines.
RVU defines are present in AF driver
(drivers/net/ethernet/marvell/octeontx2/af), header files from
AF driver are included here to avoid duplication.
Adds 'sriov_configure' to enable/disable virtual functions (VFs).
Also Initializes VF<=>PF mailbox IRQs, register handlers for
processing these mailbox messages.
Admin function (AF) handles resource allocation and configuration for
PFs and their VFs. PFs request the AF directly, via mailboxes.
Unl
This series introduces crypto(CPT) drivers(PF & VF) for Marvell
OcteonTX2 CN96XX Soc.
OcteonTX2 SOC's resource virtualization unit (RVU) supports multiple
physical and virtual functions. Each of the PF/VF's functionality is
determined by what kind of resources are attached to it. When the CPT
bloc
CPT RVU Local Functions(LFs) needs to be attached to the
PF/VF to submit the instructions to CPT.
This patch adds the interface to initialize and attach
the LFs. It also adds interface to register the LF's
interrupts.
Signed-off-by: Suheil Chandran
Signed-off-by: Lukasz Bartosik
Signed-off-by: S
Add support for the Marvell OcteonTX2 CPT virtual function
driver. This patch includes probe, PCI specific initialization
and interrupt handling.
Signed-off-by: Suheil Chandran
Signed-off-by: Lukasz Bartosik
Signed-off-by: Srujana Challa
---
drivers/crypto/marvell/octeontx2/Makefile | 4
Adds support to get engine capabilities and adds a new mailbox
to share capabilities with VF driver.
Signed-off-by: Suheil Chandran
Signed-off-by: Srujana Challa
---
.../marvell/octeontx2/otx2_cpt_common.h | 36
.../marvell/octeontx2/otx2_cpt_reqmgr.h | 51 ++
drivers/cry
Attach LFs to CPT VF to process the crypto requests and register
LF interrupts.
Signed-off-by: Suheil Chandran
Signed-off-by: Lukasz Bartosik
Signed-off-by: Srujana Challa
---
drivers/crypto/marvell/octeontx2/Makefile | 2 +-
.../marvell/octeontx2/otx2_cpt_common.h | 17 +
.../mar
CPT offload module utilises the linux crypto framework to offload
crypto processing. This patch registers supported algorithms by
calling registration functions provided by the kernel crypto API.
The module currently supports:
- AES block cipher in CBC,ECB and XTS mode.
- 3DES block cipher in CBC
CPT includes microcoded GigaCypher symmetric engines(SEs), IPsec
symmetric engines(IEs), and asymmetric engines (AEs).
Each engine receives CPT instructions from the engine groups it has
subscribed to. This patch loads microcode, configures three engine
groups(one for SEs, one for IEs and one for A
Hi Dan,
Thanks for finding and fixing this.
On Wed, 2021-01-06 at 12:25 +0300, Dan Carpenter wrote:
> The first argument to WARN() is a condition and the messages is the
> second argument is the string, so this WARN() will only display the
> __func__ part of the message.
>
> Fixes: ae832e329a8d
On Tue, 5 Jan 2021 15:02:45 +0100, Thomas Bogendoerfer wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
>
> I've split up the removal into seperate parts for different
From: Daniele Alessandrelli
Add the following additional dependencies for CRYPTO_DEV_KEEMBAY_OCS_HCU:
- HAS_IOMEM to prevent build failures
- ARCH_KEEMBAY to prevent asking the user about this driver when
configuring a kernel without Intel Keem Bay platform support.
Signed-off-by: Daniele Al
Hi Geert!
On Wed, 6 Jan 2021 09:37:11 +0100, Geert Uytterhoeven
wrote:
> Hi Thomas,
>
> CC Nemoto-san (de-facto TX49XX maintainer)
>
> On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> wrote:
>> I couldn't find any buyable product other than reference boards using
>> TX49xx CPUs. And since
On Wed, Jan 06, 2021 at 09:37:11AM +0100, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> CC Nemoto-san (de-facto TX49XX maintainer)
>
> On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> wrote:
> > I couldn't find any buyable product other than reference boards using
> > TX49xx CPUs. And since nob
On Tue, 2021-01-05 at 15:02 +0100, Thomas Bogendoerfer wrote:
> Signed-off-by: Thomas Bogendoerfer
[]
> diff --git a/drivers/dma/txx9dmac.h b/drivers/dma/txx9dmac.h
[]
> @@ -26,11 +26,6 @@
> * DMA channel.
> */
>
>
> -#ifdef CONFIG_MACH_TX49XX
> -static inline bool txx9_dma_have_SMPCHN(void
Hi Thomas,
On Wed, Jan 6, 2021 at 7:49 PM Thomas Bogendoerfer
wrote:
> On Wed, Jan 06, 2021 at 09:37:11AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
> > wrote:
> > > I couldn't find any buyable product other than reference boards using
> > > TX49xx CP
On Wed, 6 Jan 2021 21:41:24 +0100, Geert Uytterhoeven
wrote:
>> > Is that sufficient to keep it?
>>
>> for me it is. But now we probaly need some reverts then...
>
> Indeed. Fortunately not all of it, as some removals were TX4938-only.
These patches should not break RBTX4927:
net: tc35815: D
The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
On platforms with Zhaoxin CPUs supporting this X86 feature, when
crc32c-intel and crc32c-generic are both registered, system will
use crc32c-intel because its .cra_priority is greater than
crc32c-generic.
When doing lmbench3 Create
SSE4.2 on Zhaoxin CPUs are compatible with Intel. The presence of
CRC32C instruction is enumerated by CPUID.01H:ECX.SSE4_2[bit 20] = 1.
Some Zhaoxin CPUs declare support SSE4.2 instruction sets but their
CRC32C instruction are working with low performance.
Add a synthetic CPU flag to indicates tha
Low performance CRC32C instruction CPUs expect to use the driver
crc32c-generic. So remove these CPUs support from crc32c-intel.
Signed-off-by: Tony W Wang-oc
---
arch/x86/crypto/crc32c-intel_glue.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/crypto/crc32c-intel_glue.c
b/a
Some Zhaoxin CPUs declare support SSE4.2 instruction sets but
having a CRC32C instruction implementation that not working as
intended. Set low performance CRC32C flag on these CPUs for later
use.
Signed-off-by: Tony W Wang-oc
---
arch/x86/kernel/cpu/centaur.c | 7 +++
arch/x86/kernel/cpu/zha
On 22/12/2020 12:54, h...@zytor.com wrote:
> On December 21, 2020 7:01:39 PM PST, tonywwang...@zhaoxin.com wrote:
>> On December 22, 2020 3:27:33 AM GMT+08:00, h...@zytor.com wrote:
>>> On December 20, 2020 6:46:25 PM PST, tonywwang...@zhaoxin.com wrote:
On December 16, 2020 1:56:45 AM GMT+0
On 03/01/2021 05:12, Herbert Xu wrote:
> On Tue, Dec 15, 2020 at 06:28:11PM +0800, Tony W Wang-oc wrote:
>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
>> On platforms with Zhaoxin CPUs supporting this X86 feature, when
>> crc32c-intel and crc32c-generic are both registered, s
On Thu, Jan 07, 2021 at 02:19:06PM +0800, Tony W Wang-oc wrote:
> SSE4.2 on Zhaoxin CPUs are compatible with Intel. The presence of
> CRC32C instruction is enumerated by CPUID.01H:ECX.SSE4_2[bit 20] = 1.
> Some Zhaoxin CPUs declare support SSE4.2 instruction sets but their
> CRC32C instruction are
Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > The HKDF addition is used to replace the implementation in the filesystem
> > crypto extension. This code was tested by using an EXT4 encrypted file
> > system that w
On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > > The HKDF addition is used to replace the implementation in the filesystem
> > > crypto extensio
On Wed, Jan 06, 2021 at 10:59:24PM -0800, Eric Biggers wrote:
> On Thu, Jan 07, 2021 at 07:37:05AM +0100, Stephan Mueller wrote:
> > Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> > > On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > > > The HKDF addition is used
On Mon, Jan 04, 2021 at 10:50:49PM +0100, Stephan Müller wrote:
> As the kernel crypto API implements HKDF, replace the
> file-system-specific HKDF implementation with the generic HKDF
> implementation.
>
> Signed-off-by: Stephan Mueller
> ---
> fs/crypto/Kconfig | 2 +-
> fs/crypto/
On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote:
> RFC5869 specifies an extract and expand two-step key derivation
> function. The HKDF implementation is provided as a service function that
> operates on a caller-provided HMAC cipher handle.
HMAC isn't a "cipher".
> The extract fun
On 2/12/20 8:24 pm, Tobias Markus wrote:
> Hi David,
>
> I'm afraid I can't provide an exactly matching disassembly of the function
> since I've since updated to newer -rc kernels.
> Another debugging hurdle is that the specific kernel code path seems to be
> triggered by a very specific iwd cod
Am Mittwoch, dem 06.01.2021 um 23:19 -0800 schrieb Eric Biggers:
> On Mon, Jan 04, 2021 at 10:50:49PM +0100, Stephan Müller wrote:
> > As the kernel crypto API implements HKDF, replace the
> > file-system-specific HKDF implementation with the generic HKDF
> > implementation.
> >
> > Signed-off-by:
Am Mittwoch, dem 06.01.2021 um 23:30 -0800 schrieb Eric Biggers:
> On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote:
> > RFC5869 specifies an extract and expand two-step key derivation
> > function. The HKDF implementation is provided as a service function that
> > operates on a calle
35 matches
Mail list logo
