On Mon, Jul 9, 2018 at 10:09 PM, Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote: > Hello, > > This is an attempt at adding "depends || COMPILE_TEST" to all NAND > drivers that have no compile-time dependencies on arch > features/headers. > > This will hopefully help us (NAND/MTD maintainers) in detecting build > issues earlier. Unfortunately we still have a few drivers that can't > easily be modified to be arch independent. > > I tried to put all patches that only touch the NAND subsystem first, > so that they can be applied even if other patches are being discussed. > > Don't hesitate to point any missing dependencies when compiled with > COMPILE_TEST. I didn't have any problem when compiling, but that might > be because the dependencies were already selected. Looks good to me overall. > In this v2, I tried to fix all warnings/errors reported by kbuild/0day > robots. The only remaining ones are those in omap_elm.c which seems to > do some weird cpu_to_be32() conversions. I guess I could replace those > by iowrite32be() calls (or just add (__force __u32)), but I don't want > to risk a regression on this driver, so I'm just leaving it for someone > else to fix :P. Agreed, this is definedly very odd code. It looks like the intention is to write all the bits in reverse order, but four bytes at a time. I'm fairly sure the current implementation cannot work on big-endian, in particularly this line: val = cpu_to_be32(*(u32 *) &ecc[0]) >> 12; Since shifting a number after the byteswap is not well-defined. It's probably correct on little-endian, but it's not clear what the best way would be to write this is an endian-neutral way. Arnd