On Thursday 17 July 2014 17:29:31 Chen Gang wrote: > > > > COMPILE_TEST is a great tool in general, but it has its limits. > > In particular, the case for !CONFIG_IOMEM is completely obscure > > and we won't find any bugs by allowing more drivers to be built > > in those configurations, but attempting to do it would cause > > endless churn by changing each instance of 'depends on HAS_IOMEM' > > to 'depends on HAS_IOMEM || COMPILE_TEST'. > > > > Architecture members and driver members really have different tastes, > they are different roles. It really need additional discussion. > > For me, I only want to change devm_io*map*, not touch so much. But what do you gain from that? All drivers that need these functions should already 'depends on HAS_IOMEM' and if they don't, we should fix /that/ instead. I don't see this dependency as any different from a lot of others (PCI, DMAENGINE, HAVE_CLK, ...) that we use to intentionally annotate drivers that need a particular feature to be present for compilation. Do you want to do the same hack to those? > Welcome any other members' idea or suggestions. > > Note that s390 no has gained support for IOMEM, tile has it most > > of the time (when PCI is enabled, so you get it in half the > > test builds already), score should set HAS_IOMEM and doesn't > > even have public compilers, and uml doesn't even compile in > > latest mainline. Nothing else ever sets NO_IOMEM. > > > > In latest gcc and binutils, can compile score cross compiler > successfully for building kernel (but I am not quite sure whether the > compiling result are really OK, but I guess so). Ok. Would you mind sending a patch that enables HAS_IOMEM on score? > And next (maybe after finish allmodconfig for microblaze), I shall try > to let uml pass allmodconfig for linux-next tree. That is a fair goal, but it seems better to do that by ensuring we don't build any code that tries to call the MMIO functions rather than trying to make them build. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
