On Mon, 10 Aug 2020, Thomas Bogendoerfer wrote: > > > It's not just this #include, there's a couple dozen mach-* directories; > > > changing how they work would be up to the MIPS maintainers (CCed), and > > > it would certainly not be a patch that can be merged in stable@ kernels. > > > > > > arch/mips/kernel/cpu-probe.c has the same > > > > > > #ifdef CONFIG_CPU_LOONGSON64 > > > #include <loongson_regs.h> > > > > > > for example, so apparently they're good with this. So if I don't pick > > > up the patch to fix the build it would be in all likelihood merged by > > > MIPS maintainers. The only difference will be how long the build > > > remains broken and the fact that they need to worry about KVM despite > > > the presence of a specific maintainer. > > > > Ok, fair enough, but in the long-run, this should probably be fixed up > > "properly" if this arch is still being maintained. > > I have it on my todo list. My plan is to move stuff out of mach-* directories, > which aren't needed there. This should solve issues like the one here. Correct, it looks like another maintainer's oversight. The asm/mach-<platform>/ directories are there for platform variants of generic stuff found in asm/mach-generic/. So if something is not there in asm/mach-generic/, then it must not be in any other asm/mach-<plaftorm>/ subdirectory either. Regular platform headers need to go under asm/<plaftorm>/. Compare asm/mach-dec/ vs asm/dec/, or asm/mach-sibyte/ vs asm/sibyte/, and so on. So this `loongson_regs.h' piece belongs to asm/loongson64/ rather than asm/mach-loongson64/. Maciej
