mach/io.h cleanup and removal
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 of 15 patches 0 repliesNew
3 of 15 patches are in this archive. The cover letter announces 15.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 13/15 | ARM: make mach/io.h include optional | +0 | 0 replies | |
| 13/15 | ARM: make mach/io.h include optional | +0 | 0 replies | |
| 13/15 | ARM: make mach/io.h include optional | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/15] mach/io.h cleanup and removal
Quoted 9 lines · Rob Herring
Quoted 5 lines
I agree that this is the ideal, but as far as I can tell, we have a significant amount of functions that are defined in platform specific code but used in platform specific drivers. E.g. when you have a piece of code dealing with system management registers in your platform, that would be used in the cpufreq, irqchip, watchdog and more drivers.
From my quick survey, those categories are really the exception. I would guess
platform_datastructs is at least half of it. Older platforms seem to be another big chunk.
Good to hear. We can certainly take care of the platform data by moving it to include/linux/platform_data/*.h and the older platforms can usually keep exporting their header files because we won't get them to build into the same kernel with other platforms.
Quoted 2 lines
Lack of a common usb phy infrastructure is another example of custom platform functions (tegra
usb_phy.h).
Good point.
Quoted 9 lines
Quoted 3 lines
* Any symbol that is required to be visible in device drivers gets declared in
arch/arm/include/mach-*/*.h, but we are very careful about adding only the absolute minimum here.Why not
include/linux? Any includes for drivers which are either multiple arches (ahci_platform.h) or multiple ARM machines (linux/amba/pl061.h) are already there. Every platform trying to dump dozens of includes there would certainly get attention and force some clean-up.
I strongly believe that any header file should be as localized as possible:
a) no header, all declarations in the one file using it
b) header file in local directory
c) header file in per-platform directory
d) header file in per-architecture directory
e) global header file
We need to get rid of category c in order to make cross-platform kernels work. Ideally we would move everything into categories a and b, which is often possible, but for those cases where it doesn't work the logical step is to have it in arch specific code, not global.
Arnd