ARM: OMAP2+: Prevent redefinition errors for soc.h

If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once.

Signed-off-by Jon Hunter <[email protected]>

---

Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors.

[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2

 arch/arm/mach-omap2/soc.h |    4 ++++
 1 file changed, 4 insertions(+)

arch/arm/mach-omap2/soc.h +4 -0

index 0700964..6b270a0 100644
@@ -25,6 +25,9 @@
  *
  */
 
+#ifndef __ARCH_ARM_MACH_OMAP2_SOC_H
+#define __ARCH_ARM_MACH_OMAP2_SOC_H
+
 #include "omap24xx.h"
 #include "omap34xx.h"
 #include "omap44xx.h"

@@ -471,3 +474,4 @@ OMAP4_HAS_FEATURE(mpu_1_5ghz, MPU_1_5GHZ)
 
 #endif	/* __ASSEMBLY__ */
 
+#endif	/* __ARCH_ARM_MACH_OMAP2_SOC_H */

Signature · 1 line

1.7.9.5

Quoted 7 lines · Jon Hunter

If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once.

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors.

[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2

As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further.

We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways.

Including the files directly should fix this easily, if not let me know.

Quoted 23 lines · Tony Lindgren

Quoted 7 lines · Jon Hunter

If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once.

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors.

[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2

As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further.

We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways.

Quoted 2 lines

Including the files directly should fix this easily, if not let me know.

The alternative fix is to ensure anyone including dmtimer.h also includes soc.h. However, I did not know if we should have such a dependency. If you are ok with that then that is what I will do for now. It is not a massive change.

Quoted 28 lines · Jon Hunter

Quoted 25 lines · Tony Lindgren

Quoted 7 lines · Jon Hunter

If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once.

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors.

[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2

As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further.

We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways.

Including the files directly should fix this easily, if not let me know.

Quoted 4 lines

The alternative fix is to ensure anyone including dmtimer.h also includes soc.h. However, I did not know if we should have such a dependency. If you are ok with that then that is what I will do for now. It is not a massive change.

Do you mean anything under mach-omap2/*.c including dmtimer.h also needs to also include soc.h? If sounds OK to me as long as we don't need to include soc.h outside mach-omap2.

Quoted 34 lines · Tony Lindgren

Quoted 32 lines · Jon Hunter

Quoted 17 lines · Tony Lindgren

Quoted 7 lines · Jon Hunter

If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once.

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors.

[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2

Quoted 8 lines

As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further.

We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways.

Including the files directly should fix this easily, if not let me know.

The alternative fix is to ensure anyone including dmtimer.h also includes soc.h. However, I did not know if we should have such a dependency. If you are ok with that then that is what I will do for now. It is not a massive change.

Quoted 3 lines

Do you mean anything under mach-omap2/*.c including dmtimer.h also needs to also include soc.h? If sounds OK to me as long as we don't need to include soc.h outside mach-omap2.

Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is indirectly including soc.h. The function omap_dm_timer_populate_errata() is using the cpu_is_xxxx macros. So maybe I should move this to into platform data. Is that better?

Quoted 36 lines · Jon Hunter

Quoted 34 lines · Tony Lindgren

Quoted 32 lines · Jon Hunter

Quoted 17 lines · Tony Lindgren

Quoted 7 lines · Jon Hunter

If the header soc.h is included more than once in a source (for example once directly by the source file and once indirectly by another header file), then the compiler will generate redefintion errors for the macros in soc.h. Prevent this by only allowing the content in soc.h to be included once.

Signed-off-by Jon Hunter <[email protected]>

Quoted 8 lines

---

Please note that I ran into this problem when rebasing my dmtimer fixes series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h in dmtimer.h and I found several other files including dmtimer.h are also including soc.h and so generate a lot of errors.

[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2

Quoted 8 lines

As these headers are private to mach-omap2, I'd rather not allow including them more than once so we can eventually clean up the includes further.

We should include the headers directly where used, except for the legacy board-*.c files that will be going away anyways.

Including the files directly should fix this easily, if not let me know.

The alternative fix is to ensure anyone including dmtimer.h also includes soc.h. However, I did not know if we should have such a dependency. If you are ok with that then that is what I will do for now. It is not a massive change.

Quoted 8 lines

Quoted 3 lines

Do you mean anything under mach-omap2/*.c including dmtimer.h also needs to also include soc.h? If sounds OK to me as long as we don't need to include soc.h outside mach-omap2.

Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is indirectly including soc.h. The function omap_dm_timer_populate_errata() is using the cpu_is_xxxx macros. So maybe I should move this to into platform data. Is that better?

I think I already fixed that up in the cleanup branch. I've now merged that into the omap-for-v3.8/dt branch. The only remaining cpu_is_omap usage there is:

$ grep cpu_is_omap arch/arm/plat-omap/*.[chS]

arch/arm/plat-omap/fb.c:        if (cpu_is_omap24xx()) {
arch/arm/plat-omap/fb.c:        } else if (cpu_is_omap34xx()) {

So maybe see what needs to be patches on top of omap-for-v3.8/dt?

Sorry, I meant in the fixes series I have posted for dmtimer, I am adding a new function called omap_dm_timer_populate_errata() that is using cpu_is_xxxx() [1]. I had done this a while back, but now I see that we want to get away from doing that right?

I was planning on sending you a pull request for that series on Monday but now I am wondering if I should fix this now or later. I was hoping this series would make 3.8.

[1] http://marc.info/?l=linux-omap&m=135249008128365&w=2

Quoted 5 lines · Jon Hunter

Sorry, I meant in the fixes series I have posted for dmtimer, I am adding a new function called omap_dm_timer_populate_errata() that is using cpu_is_xxxx() [1]. I had done this a while back, but now I see that we want to get away from doing that right?

Yes. Looks like everything we have under plat-omap can be moved to live under drivers eventually, so let's not use cpu_is_omap there either. For legacy boot, you can use pdata->timer_capability for passing that?

Quoted 3 lines

I was planning on sending you a pull request for that series on Monday but now I am wondering if I should fix this now or later. I was hoping this series would make 3.8.

Yeah, sounds like that should be fixed though as we still have a bit of time early next week.