Skip to content

RFC ARM: Add default system.h and uncompress.h

Rob Herring linux-arm-kernel 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest0 of 3 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 3 patches the cover letter announces are in this archive.

Reviews trailers per patch

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

Read the v1 thread

Cover letter [RFC PATCH 0/3] ARM: Add default system.h and uncompress.h

Nicolas,

Quoted 11 lines · Nicolas Pitre
Quoted 8 lines · Rob Herring

From: Rob Herring <[email protected]>

This is a relatively simple way to remove the platform requirement for some header files without making changes in every existing platform. It's perhaps not a solution for the difficult cases, but can get the simple cases out of the way making it clear what remains to be fixed. I've done this for system.h and uncompress.h so far. timex.h and io.h may be additional candidates.

Quoted 11 lines

I'm of two minds about this. It is true that this makes things easy and would avoid some of the #ifdef'ery that is otherwise necessary. On the other hand this gives us more opportunity for procrastinating and not really do a complete and thorough job. It would also be easier for some platform to sneak in some of those header files to work around some shortcomings in the generic version which is not helping maintainers keeping a good discipline. AS we are working on this, I might prefer that mistakes do break the build rather than silently causing a fallback with a dummy generic version to be picked up which might only cause problems at run time much later.

I just threw this out as an option.

I certainly view this as somewhat temporary, but just longer lived than a single patch series and simpler that a bunch of temporary HAVE_FOO_HEADER defines. Ultimately, the headers could just get rolled into their parent asm header once all the platforms are converted over. I don't view it as procrastinating, but allows platforms to be cleaned up independently and spreads the work to others. The decision to move gpio code into drivers/gpio is a good example. There was clear path and it all went very quickly. It also allows focusing on the harder problems while people are F2F.

Quoted 4 lines

A Linaro event is taking place next week in England where a focused effort will be deployed to work on this. Let's see how much we'll be able to clean up.

Yes, I'm well aware of that. I'll participate remotely as much as I can. Let me know how I can help.

Rob