lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220609213652.GA115440-robh@kernel.org>
Date:   Thu, 9 Jun 2022 15:36:52 -0600
From:   Rob Herring <robh@...nel.org>
To:     Yoan Picchi <yoan.picchi@....com>
Cc:     Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>, qat-linux@...el.com,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andre Przywara <andre.przywara@....com>,
        Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH 2/2] Removes the x86 dependency on the QAT drivers

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).

The only testing obligation you have is compiling for BE. 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.

Also, with the dependency, no one can test the driver without modifying 
the kernel and if it does work as-is, then one has to upstream a change 
and then wait for it to show up in distro kernels. You could mitigate 
the first part with COMPILE_TEST.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ