Skip to content

mach/io.h cleanup and removal

Arnd Bergmann linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest6 of 15 patches 0 repliesNew

6 of 15 patches are in this archive. The cover letter announces 15.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
13/15ARM: make mach/io.h include optional+0 -01 reply
13/15ARM: make mach/io.h include optional+0 -01 reply
13/15ARM: make mach/io.h include optional+0 -03 replies
13/15ARM: make mach/io.h include optionalarch/arm/mach-iop13xx/include/mach/io.h arch/arm/mach-iop13xx/include/mach/iop13xx.h arch/arm/mach-iop13xx/io.c +1 more+13 -448 replies
13/15ARM: make mach/io.h include optional+0 -00 replies
13/15ARM: make mach/io.h include optional+0 -00 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 00/15] mach/io.h cleanup and removal
Quoted 9 lines · Tony Lindgren

Yes should be just the legacy drivers needing this for most part, so that's currently most of omap1 drivers for us.

Anyways I'm using plat/omap-iomap.h for the name, so if somebody has better ideas for naming to avoid further search and replace later on, let me know.

I guess in the long run we could have

Quoted 7 lines

#include <mach-omap1/iomap.h>

instead of

#include <plat/omap-iomap.h>

as the plat can't be used for multi-subarch builds.

I think it /could/ be used, we just need to make a definite decision which way we want to go for header files that are defined by a platform and used by code outside of that platform such as device drivers.

The two main approaches that I can see are

a) make every header file name unique for platforms that you want to build together, and just add every path at the compiler command line. Not too much work, but somewhat error prone when you start having file name conflicts.

b) move all platform specific header files into a directory named after the platform and change all device drivers using this. Lots of work, but probably better in the long run.

Arnd