Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220607165840.66931-1-yoan.picchi@arm.com> <20220607165840.66931-3-yoan.picchi@arm.com>
 <20220609213652.GA115440-robh@kernel.org> <20220610114840.10db23ea@donnerap.cambridge.arm.com>
 <YqcUXrFGO+QVMKBd@silpixa00400314>
In-Reply-To: <YqcUXrFGO+QVMKBd@silpixa00400314>
From:   Rob Herring <robh@kernel.org>
Date:   Mon, 13 Jun 2022 07:44:42 -0600
Message-ID: <CAL_JsqJ_mjR8tbUu0n4AxXSVGtDOMTnRZTBRyvOAwe28tGXamA@mail.gmail.com>
Subject: Re: [PATCH 2/2] Removes the x86 dependency on the QAT drivers
To:     Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Cc:     Andre Przywara <andre.przywara@arm.com>,
        Yoan Picchi <yoan.picchi@arm.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S . Miller" <davem@davemloft.net>, qat-linux@intel.com,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jun 13, 2022 at 4:41 AM Giovanni Cabiddu
<giovanni.cabiddu@intel.com> wrote:
>
> On Fri, Jun 10, 2022 at 11:48:40AM +0100, Andre Przywara wrote:
> > On Thu, 9 Jun 2022 15:36:52 -0600
> > Rob Herring <robh@kernel.org> wrote:
> >
> > Hi,
> >
> > > On Tue, Jun 07, 2022 at 04:58:40PM +0000, Yoan Picchi wrote:
> > > > This dependency looks outdated. After the previous patch, we have been able
> > > > to use this driver to encrypt some data and to create working VF on arm64.
> > > > We have not tested it yet on any big endian machine, hence the new dependency
> > >
> > > For the subject, use prefixes matching the subsystem (like you did on
> > > patch 1).
> Just to add on this, patches to the qat driver should have the following
> headline:
>     crypto: qat -
> not
>     crypto: qat:
>
> > >
> > > The only testing obligation you have is compiling for BE.
> >
> > So I just compiled for arm64 BE, powerpc BE & LE, and riscv again:
> > $ file qat_c62xvf.ko
> > qat_c62xvf.ko: ELF 64-bit MSB relocatable, ARM aarch64, version 1 (SYSV),
> > BuildID[sha1]=630cc0ee5586c7aeb6e0ab5567ce2f2f7cc46adf, with debug_info,
> > not stripped
> > qat_c62xvf.ko: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500,
> > version 1 (SYSV), BuildID[sha1]=4090ba181cf95f27108bf3ecde0776f12ef2b636,
> > not stripped
> > qat_c62xvf.ko: ELF 64-bit LSB relocatable, 64-bit PowerPC or cisco 7500,
> > version 1 (SYSV), BuildID[sha1]=2cb0fd09d5bc36c8918fcd061c9f3dac1546cf0d,
> > not stripped
> > qat_c62xvf.ko: ELF 64-bit LSB relocatable, UCB RISC-V, version 1 (SYSV),
> > BuildID[sha1]=bfaa53df7e9aad79d3ab4c05e75ca9169227f6b8, not stripped
> >
> > All built without errors or warnings, for every of the enabled drivers.
> >
> > > If kconfig was
> > > supposed to capture what endianness drivers have been tested or not
> > > tested with, then lots of drivers are missing the dependency. Kconfig
> > > depends/select entries should generally be either to prevent compile
> > > failures (you checked PPC, RiscV, etc.?) or to hide drivers *really*
> > > specific to a platform. IMO, we should only have !CPU_BIG_ENDIAN if it
> > > is known not to work and not easily fixed.
> >
> > Fair enough, I leave that decision to Giovanni. I have plans to test this
> > with BE, but getting a BE setup on a server is not trivial, both for
> > userland and actual booting, so this will take some time. We just didn't
> > want to block this on some BE concerns.
> Just inspecting the code I can see we are not handling BE in the logic
> that builds FW descriptors.
> My preference would be to keep !CPU_BIG_ENDIAN until the driver is fixed
> and tested.

Okay, then at least add '|| COMPILE_TEST' so that allyesconfig builds build it.

Rob