Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1584100028-21279-1-git-send-email-schalla@marvell.com>
 <20200320053149.GC1315@sol.localdomain> <DM5PR18MB231111CEBDCDF734FA8C670BA0F50@DM5PR18MB2311.namprd18.prod.outlook.com>
 <CAKv+Gu_G4=Dn+6chjk1dQFMXm1aGU8QQZMmy94L5LicmR3itKQ@mail.gmail.com>
 <DM5PR18MB23111DB74B74BED1E08E0DD3A0F00@DM5PR18MB2311.namprd18.prod.outlook.com>
 <DM5PR18MB2311BB76C6A1F5C90B5D6A86A0DD0@DM5PR18MB2311.namprd18.prod.outlook.com>
In-Reply-To: <DM5PR18MB2311BB76C6A1F5C90B5D6A86A0DD0@DM5PR18MB2311.namprd18.prod.outlook.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 13 Apr 2020 15:47:43 +0200
Message-ID: <CAKv+Gu9=bzFkDkFrkkmB-xM_Ff4ECR9Q5rPqmby6fijZsQmG0Q@mail.gmail.com>
Subject: Re: [EXT] Re: [PATCH v2 0/4] Add Support for Marvell OcteonTX Cryptographic
To:     Srujana Challa <schalla@marvell.com>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Narayana Prasad Raju Athreya <pathreya@marvell.com>,
        Suheil Chandran <schandran@marvell.com>,
        "arno@natisbad.org" <arno@natisbad.org>,
        "bbrezillon@kernel.org" <bbrezillon@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Mon, 13 Apr 2020 at 15:21, Srujana Challa <schalla@marvell.com> wrote:
>
> > Subject: RE: [EXT] Re: [PATCH v2 0/4] Add Support for Marvell OcteonTX
> > Cryptographic
> >
> > > On Fri, 20 Mar 2020 at 06:47, Srujana Challa <schalla@marvell.com> wr=
ote:
> > > >
> > > > > On Fri, Mar 13, 2020 at 05:17:04PM +0530, Srujana Challa wrote:
> > > > > > The following series adds support for Marvell Cryptographic Acc=
elerarion
> > > > > > Unit (CPT) on OcteonTX CN83XX SoC.
> > > > > >
> > > > > > Changes since v1:
> > > > > > * Replaced CRYPTO_BLKCIPHER with CRYPTO_SKCIPHER in Kconfig.
> > > > > >
> > > > > > Srujana Challa (4):
> > > > > >   drivers: crypto: create common Kconfig and Makefile for Marve=
ll
> > > > > >   drivers: crypto: add support for OCTEON TX CPT engine
> > > > > >   drivers: crypto: add the Virtual Function driver for CPT
> > > > > >   crypto: marvell: enable OcteonTX cpt options for build
> > > > >
> > > > > There's no mention of testing.  Did you try
> > > > > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=3Dy?
> > > > >
> > > > Yes, the crypto self-tests are passed.
> > >
> > > *which* selftests are passed? Please confirm that they all passed wit=
h
> > > that kconfig option set
> > Apologies. I have overlooked the config option, I thought it was
> > CONFIG_CRYPTO_MANAGER_DISABLE_TESTS, all crypto self-tests are passed
> > with this option disabled. I have started verifying with
> > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=3Dy, I am getting few errors for
> > unsupported input lengths, will submit the patch with fixes.
>
> We confirmed that the failures are with unsupported lengths on our hardwa=
re, for some lengths we can resolve the issue by having validation checks i=
n the driver but for some unsupported cases "testmgr.c" is excepting always=
 success, I am still unsure how to fix/prevent these kind of failures. Can =
anyone please kindly help me out how to proceed on this issue.
> Thanks for your help.

You need to allocate fallbacks for the modes that your driver cannot
support. There are plenty of examples of that in the kernel tree.