On Mon, 29 Jul 2019 at 13:32, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Mon, Jul 29, 2019 at 11:55 AM Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > The generic aegis128 software crypto driver recently gained support > > for using SIMD intrinsics to increase performance, for which it > > uncondionally #include's the <asm/simd.h> header. Unfortunately, > > this header does not exist on many architectures, resulting in > > build failures. > > > > Since asm-generic already has a version of simd.h, let's make it > > a mandatory header so that it gets instantiated on all architectures > > that don't provide their own version. > > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > Looks good to me, if you want this to go through the crypto tree, > > Acked-by: Arnd Bergmann <arnd@xxxxxxxx> > Thanks. > I noticed that this is the first such entry here, and went looking for > other candidates: > > $ git grep -h generic-y arch/*/include/asm/Kbuild | sort | uniq -c | > sort -nr | head -n 30 > 24 generic-y += mm-arch-hooks.h > 23 generic-y += trace_clock.h > 22 generic-y += preempt.h > 21 generic-y += mcs_spinlock.h > 21 generic-y += irq_work.h > 21 generic-y += irq_regs.h > 21 generic-y += emergency-restart.h > 20 generic-y += mmiowb.h > 19 generic-y += local.h > 18 generic-y += word-at-a-time.h > 18 generic-y += kvm_para.h > 18 generic-y += exec.h > 18 generic-y += div64.h > 18 generic-y += compat.h > 17 generic-y += xor.h > 17 generic-y += percpu.h > 17 generic-y += local64.h > 17 generic-y += device.h > 16 generic-y += kdebug.h > 15 generic-y += dma-mapping.h > 14 generic-y += vga.h > 14 generic-y += topology.h > 14 generic-y += kmap_types.h > 14 generic-y += hw_irq.h > 13 generic-y += serial.h > 13 generic-y += kprobes.h > 13 generic-y += fb.h > 13 generic-y += extable.h > 13 generic-y += current.h > 12 generic-y += sections.h > > It looks like there are a number of these that could be handled the > same way. Should we do that for the asm-generic tree afterwards? > I guess it depends whether any dependencies on those headers exist in code that is truly generic. If they are only needed by some common infrastructure that cannot be enabled for a certain architecture anyway, I don't think making it a mandatory header is appropriate. So I think the question is whether the first column and the number of per-arch instances of that header add up to 25 (disregarding the exception for arch/um for now)
