On Tue, Jul 07, 2026 at 04:02:28PM +0200, Harald Freudenberger wrote: > On 2026-07-07 11:38, Cornelia Huck wrote: > > On Mon, Jul 06 2026, Harald Freudenberger <[email protected]> wrote: > > > > > This patch series extends the s390 qemu CPACF support to be able to > > > run a subset of the CPACF instruction cross platform. There have been > > > requests on the kernel crypto mailing list about a way to test > > > s390 specific crypto implementations. For example a way to test > > > s390 CPACF exploitation code like the s390_aes.ko kernel module. > > > > > > So here now is a set of patches verified on x86 and s390 which > > > over (slow but working) support for a subset of the subfunctions of > > > some of the CPACF instructions. > > > > Hi, > > > > I wanted to pick this, but unfortunately, there are some problems with > > it, as spotted by checkpatch (sadly, I did not see this earlier, and > > softfreeze is upon us...) > > > > - Licensing information: new files (e.g. cpacf.h) must use an SPDX > > identifier instead of licence boilerplate text - this needs to be > > fixed > > - some files are using tabs instead of spaces in some places > > - there are also some other moans (less important), but you may want to > > look at them anyway (the long lines are not really a problem) > > > > Cornelia > > Yes, I saw these checkpatch complains but as nobody else seems to obey > to the checkpatch findings I ignored most of them.
That is very much the wrong conclusion to draw. Our existing in-tree code may not be clean on checkpatch, because we change checkpatch rules over time but we don't retrospectively change existing code. New code is expected to be clean with checkpatch unless there are some genuine false positives which can't be reasonably avoided. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
