OMAP: use fncpy to copy the PM code functions to SRAM

PATCH New jean.pihet at newoldbits.com 4 participants 14 messages Jan 14, 2011 – Jan 19, 2011

Subsystems (2)

Arm (32-bit) Arm sub-architectures

lore

Share & tools

lore

jean.pihet at newoldbits.com

author

2011-01-14 15:21 UTC #0 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

From: Jean Pihet <[email protected]>

The new fncpy API is better suited for copying some code to SRAM at runtime. This patch changes the ad-hoc code to the more generic fncpy API.

Tested OK on OMAP3 in low power modes (RET/OFF)
with !CONFIG_THUMB2_KERNEL

Signed-off-by Jean Pihet <[email protected]>

---
 arch/arm/plat-omap/sram.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

arch/arm/plat-omap/sram.c +3 -4

index e26e504..e2982b0 100644
@@ -23,7 +23,7 @@
 
 #include <asm/tlb.h>
 #include <asm/cacheflush.h>
-
+#include <asm/fncpy.h>
 #include <asm/mach/map.h>
 
 #include <plat/sram.h>

@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 	omap_sram_ceil -= size;
 	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
-	memcpy((void *)omap_sram_ceil, start, size);
-	flush_icache_range((unsigned long)omap_sram_ceil,
-		(unsigned long)(omap_sram_ceil + size));
+
+	fncpy((void *)omap_sram_ceil, start, size);
 
 	return (void *)omap_sram_ceil;
 }

Signature · 1 line

1.7.2.3

Jean Pihet

author

2011-01-14 15:23 UTC #1 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 10 lines · On Fri, Jan 14, 2011 at 4:21 PM, <[email protected]> wrote:

From: Jean Pihet <[email protected]>
The new fncpy API is better suited for copying some code to SRAM at runtime. This patch changes the ad-hoc code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
with !CONFIG_THUMB2_KERNEL
Signed-off-by Jean Pihet <[email protected]>

This patch depends on Dave's '[PATCH v3 1/1] ARM: Thumb-2: Symbol manipulation macros for function' patch, cf.
http://marc.info/?l=linux-arm-kernel&m=129495865831165&w=2

Regards,
Jean

Quoted 33 lines

---
?arch/arm/plat-omap/sram.c | ? ?7 +++----
?1 files changed, 3 insertions(+), 4 deletions(-)
arch/arm/plat-omap/sram.c +0 -0
index e26e504..e2982b0 100644
@@ -23,7 +23,7 @@
 
?#include <asm/tlb.h>
?#include <asm/cacheflush.h>
arch/arm/plat-omap/sram.c +1 -1
-
+#include <asm/fncpy.h>
?#include <asm/mach/map.h>
?#include <plat/sram.h>
arch/arm/plat-omap/sram.c +2 -4
@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 ? ? ? ?omap_sram_ceil -= size;
 ? ? ? ?omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
- ? ? ? memcpy((void *)omap_sram_ceil, start, size);
- ? ? ? flush_icache_range((unsigned long)omap_sram_ceil,
- ? ? ? ? ? ? ? (unsigned long)(omap_sram_ceil + size));
+
+ ? ? ? fncpy((void *)omap_sram_ceil, start, size);
 
 ? ? ? ?return (void *)omap_sram_ceil;
 ?}
--
1.7.2.3

Russell King - ARM Linux

2011-01-14 15:58 UTC #2 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

In reply to jean.pihet at newoldbits.com

Quoted 28 lines · jean.pihet at newoldbits.com

From: Jean Pihet <[email protected]>
The new fncpy API is better suited for copying some code to SRAM at runtime. This patch changes the ad-hoc code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
with !CONFIG_THUMB2_KERNEL
Signed-off-by Jean Pihet <[email protected]>
---
 arch/arm/plat-omap/sram.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)
arch/arm/plat-omap/sram.c +1 -1
index e26e504..e2982b0 100644
@@ -23,7 +23,7 @@
 
 #include <asm/tlb.h>
 #include <asm/cacheflush.h>
-
+#include <asm/fncpy.h>
 #include <asm/mach/map.h>
 
 #include <plat/sram.h>

arch/arm/plat-omap/sram.c void * omap_sram_push(void * start, unsigned long size) · line 257

Quoted 10 lines

arch/arm/plat-omap/sram.c +2 -3

@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 	omap_sram_ceil -= size;
 	omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
-	memcpy((void *)omap_sram_ceil, start, size);
-	flush_icache_range((unsigned long)omap_sram_ceil,
-		(unsigned long)(omap_sram_ceil + size));
+
+	fncpy((void *)omap_sram_ceil, start, size);
 
 	return (void *)omap_sram_ceil;

That's actually wrong usage, as you won't get the T bit set if the original function had it.

The right solution to this is to change omap_sram_push() to become just an allocator, and then use fncpy() outside of that.

So:

extern int my_func_size;
extern void my_func(int blah);
void (*sram_my_func)(int);

	void *sram = omap_sram_push(my_func_size);
	if (sram)
		sram_my_func = fncpy(sram, my_func, my_func_size);

Two benefits: 1. you get the thumb mode bit propagated (which is the point of fncpy), and 2. you get the security of type safety between my_func and the sram function pointer.

If you cast things to a void pointer and ignore the return value of fncpy then you lose the whole point of this API _and_ any form of type safety.

Jean Pihet

author

2011-01-14 16:13 UTC #3 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 38 lines · Russell King - ARM Linux

Quoted 37 lines · jean.pihet at newoldbits.com
From: Jean Pihet <[email protected]>
The new fncpy API is better suited for copying some code to SRAM at runtime. This patch changes the ad-hoc code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
with !CONFIG_THUMB2_KERNEL
Signed-off-by Jean Pihet <[email protected]>
---
?arch/arm/plat-omap/sram.c | ? ?7 +++----
?1 files changed, 3 insertions(+), 4 deletions(-)
arch/arm/plat-omap/sram.c +0 -0
index e26e504..e2982b0 100644
@@ -23,7 +23,7 @@
 
?#include <asm/tlb.h>
?#include <asm/cacheflush.h>
arch/arm/plat-omap/sram.c +1 -1
-
+#include <asm/fncpy.h>
?#include <asm/mach/map.h>
?#include <plat/sram.h>
arch/arm/plat-omap/sram.c +2 -3
@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 ? ? ? omap_sram_ceil -= size;
 ? ? ? omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
- ? ? memcpy((void *)omap_sram_ceil, start, size);
- ? ? flush_icache_range((unsigned long)omap_sram_ceil,
- ? ? ? ? ? ? (unsigned long)(omap_sram_ceil + size));
+
+ ? ? fncpy((void *)omap_sram_ceil, start, size);
 

Quoted 4 lines

arch/arm/plat-omap/sram.c void * omap_sram_push(void * start, unsigned long size) · line 257
Quoted 1 line
arch/arm/plat-omap/sram.c +0 -0
 ? ? ? return (void *)omap_sram_ceil;
That's actually wrong usage, as you won't get the T bit set if the original function had it.

Oops ok got it.

Quoted 6 lines

The right solution to this is to change omap_sram_push() to become just an allocator, and then use fncpy() outside of that.
So:

Quoted 7 lines

extern int my_func_size;
extern void my_func(int blah);
void (*sram_my_func)(int);
? ? ? ?void *sram = omap_sram_push(my_func_size);
? ? ? ?if (sram)
? ? ? ? ? ? ? ?sram_my_func = fncpy(sram, my_func, my_func_size);

Is the name 'omap_sram_push' wrong then?
What about the following?
@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)

       omap_sram_ceil -= size;
       omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));

- memcpy((void *)omap_sram_ceil, start, size);
- flush_icache_range((unsigned long)omap_sram_ceil,
- (unsigned long)(omap_sram_ceil + size));

- return (void *)omap_sram_ceil;
+ return fncpy((void *)omap_sram_ceil, start, size);

Quoted 7 lines

Two benefits: 1. you get the thumb mode bit propagated (which is the point of fncpy), and 2. you get the security of type safety between my_func and the sram function pointer.
If you cast things to a void pointer and ignore the return value of fncpy then you lose the whole point of this API _and_ any form of type safety.

Thanks for reviewing the patch.

Regards,
Jean

Russell King - ARM Linux

2011-01-14 17:34 UTC #4 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Review void * omap_sram_push(void * start, unsigned long size)

Quoted 12 lines · Jean Pihet

Is the name 'omap_sram_push' wrong then?
What about the following?

(quoted diff) +0 -0

@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
       omap_sram_ceil -= size;
       omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
 -     memcpy((void *)omap_sram_ceil, start, size);
 -     flush_icache_range((unsigned long)omap_sram_ceil,
 -             (unsigned long)(omap_sram_ceil + size));
 
 -     return (void *)omap_sram_ceil;
 +    return fncpy((void *)omap_sram_ceil, start, size);

It's more correct, but still missing out on the type safety which we've tried to provide with fncpy. Note also the other issue with Dave Martin has raised though - this isn't ready for merging yet.

Jean Pihet

author

2011-01-17 14:01 UTC #5 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Jean Pihet

Is the name 'omap_sram_push' wrong then?
What about the following?

(quoted diff) +0 -0

@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 ? ? ? ?omap_sram_ceil -= size;
 ? ? ? ?omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
 ?- ? ? memcpy((void *)omap_sram_ceil, start, size);
 ?- ? ? flush_icache_range((unsigned long)omap_sram_ceil,
 ?- ? ? ? ? ? ? (unsigned long)(omap_sram_ceil + size));

Quoted 5 lines

Quoted 2 lines
(quoted diff) +0 -0
 ?- ? ? return (void *)omap_sram_ceil;
?+ ? ?return fncpy((void *)omap_sram_ceil, start, size);
It's more correct, but still missing out on the type safety which we've tried to provide with fncpy.

IIUC the type of the function is propagated from the 2nd argument (funcp) to the return value, which is fine here. The (void)* is here only to avoid a warning thrown by memcpy.

Quoted 2 lines

?Note also the other issue with Dave Martin has raised though - this isn't ready for merging yet.

Ok I am using the latest version now and will re-spin the patch.

Regards,
Jean

Dave Martin

2011-01-17 15:46 UTC #6 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 13 lines · Jean Pihet

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Jean Pihet

Is the name 'omap_sram_push' wrong then?
What about the following?

(quoted diff) +0 -0

@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 ? ? ? ?omap_sram_ceil -= size;
 ? ? ? ?omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
 ?- ? ? memcpy((void *)omap_sram_ceil, start, size);
 ?- ? ? flush_icache_range((unsigned long)omap_sram_ceil,
 ?- ? ? ? ? ? ? (unsigned long)(omap_sram_ceil + size));

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
(quoted diff) +0 -0
 ?- ? ? return (void *)omap_sram_ceil;
?+ ? ?return fncpy((void *)omap_sram_ceil, start, size);
It's more correct, but still missing out on the type safety which we've tried to provide with fncpy.
IIUC the type of the function is propagated from the 2nd argument (funcp) to the return value, which is fine here. The (void)* is here only to avoid a warning thrown by memcpy.

I think Russell's argument was that the compiler will not notice if you mismatch the return type and the function to be copied, because the casts to/from void * make the compiler blind to the real types involved. So:

int f(int);
size_t size_of_f;

void *buffer;
int (*_copied_f1)(int);
char *(*_copied_f2)(char *);

_copied_f1 = fncpy(buffer, f, size_of_f); /* OK */ _copied_f2 = fncpy(buffer, f, size_of_f); /* compile error */ _copied_f1 = omap_sram_push(f, size_of_f); /* OK */ _copied_f2 = opam_sram_push(f, size_of_f); /* type mismatch, but compilation succeeds */

One way to work around this is would be to make omap_sram_push() a macro:

#define omap_sram_push(funcp, size) \
    (typeof(funcp))_do_omap_sram_push((void *)(funcp), size)

... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). Providing _do_omap_sram_push() is not called directly, this should now be type-safe.

Cheers
---Dave

Jean Pihet

author

2011-01-18 12:05 UTC #7 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Dave, Russell,

Quoted 44 lines · Dave Martin

Quoted 13 lines · Jean Pihet
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Jean Pihet
Is the name 'omap_sram_push' wrong then?
What about the following?
(quoted diff) +0 -0
@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
 
 ? ? ? ?omap_sram_ceil -= size;
 ? ? ? ?omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
 ?- ? ? memcpy((void *)omap_sram_ceil, start, size);
 ?- ? ? flush_icache_range((unsigned long)omap_sram_ceil,
 ?- ? ? ? ? ? ? (unsigned long)(omap_sram_ceil + size));
 
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
(quoted diff) +0 -0
 ?- ? ? return (void *)omap_sram_ceil;
?+ ? ?return fncpy((void *)omap_sram_ceil, start, size);
It's more correct, but still missing out on the type safety which we've tried to provide with fncpy.
IIUC the type of the function is propagated from the 2nd argument (funcp) to the return value, which is fine here. The (void)* is here only to avoid a warning thrown by memcpy.
I think Russell's argument was that the compiler will not notice if you mismatch the return type and the function to be copied, because the casts to/from void * make the compiler blind to the real types involved. ?So:
int f(int);
size_t size_of_f;
void *buffer;
int (*_copied_f1)(int);
char *(*_copied_f2)(char *);
_copied_f1 = fncpy(buffer, f, size_of_f); /* OK */ _copied_f2 = fncpy(buffer, f, size_of_f); /* compile error */ _copied_f1 = omap_sram_push(f, size_of_f); /* OK */ _copied_f2 = opam_sram_push(f, size_of_f); /* type mismatch, but compilation succeeds */
One way to work around this is would be to make omap_sram_push() a macro:

Quoted 8 lines

#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.

Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.

New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.

Quoted 4 lines

Cheers
---Dave

Thanks,
Jean

Russell King - ARM Linux

2011-01-18 23:42 UTC #8 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 13 lines · Jean Pihet

Dave, Russell,
Quoted 10 lines · Dave Martin
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.

Quoted 5 lines

Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.
New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.

Looks good, thanks. Next problem to sort out is who's taking the patches...

Tony Lindgren

2011-01-18 23:44 UTC #9 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 14 lines · Russell King - ARM Linux

Quoted 13 lines · Jean Pihet
Dave, Russell,
Quoted 10 lines · Dave Martin
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.

Quoted 8 lines

Quoted 5 lines
Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.
New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.
Looks good, thanks. Next problem to sort out is who's taking the patches...

You can take them but we should have at least Kevin test and ack them.

Tony

Jean Pihet

author

2011-01-19 08:06 UTC #10 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 18 lines · Tony Lindgren

Quoted 17 lines · Russell King - ARM Linux
Quoted 16 lines · Jean Pihet
Dave, Russell,
Quoted 10 lines · Dave Martin
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.
Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.
Looks good, thanks. ?Next problem to sort out is who's taking the patches...
You can take them but we should have at least Kevin test and ack them.

Sure, this needs some testing on OMAP1 & 2 platforms. It has only been compile tested on those (means: compile OK, functions types mismatches fixed).

Anyone with OMAP1 & 2 boards willing to test?

Thanks,
Jean

Quoted 3 lines

Tony

Tony Lindgren

2011-01-19 19:10 UTC #11 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 25 lines · Jean Pihet

Quoted 24 lines · Tony Lindgren
Quoted 22 lines · Russell King - ARM Linux
Quoted 13 lines · Jean Pihet
Dave, Russell,
Quoted 10 lines · Dave Martin
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.
Quoted 5 lines
Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.
New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.
Looks good, thanks. ?Next problem to sort out is who's taking the patches...

Quoted 6 lines

Quoted 1 line
You can take them but we should have at least Kevin test and ack them.
Sure, this needs some testing on OMAP1 & 2 platforms. It has only been compile tested on those (means: compile OK, functions types mismatches fixed).
Anyone with OMAP1 & 2 boards willing to test?

Can you please repost the whole set one more time or have them in some git branch? That way I can pull them into linux-omap master branch for testing to make sure omap1 and 2 boards don't break.

Tony

Jean Pihet

author

2011-01-19 21:37 UTC #12 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Hi Tony,

Quoted 31 lines · Tony Lindgren

Quoted 30 lines · Jean Pihet
Quoted 18 lines · Tony Lindgren
Quoted 17 lines · Russell King - ARM Linux
Quoted 16 lines · Jean Pihet
Dave, Russell,
Quoted 10 lines · Dave Martin
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.
Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.
Looks good, thanks. ?Next problem to sort out is who's taking the patches...
You can take them but we should have at least Kevin test and ack them.
Sure, this needs some testing on OMAP1 & 2 platforms. It has only been compile tested on those (means: compile OK, functions types mismatches fixed).

Quoted 5 lines

Quoted 1 line
Anyone with OMAP1 & 2 boards willing to test?
Can you please repost the whole set one more time or have them in some git branch? That way I can pull them into linux-omap master branch for testing to make sure omap1 and 2 boards don't break.

There is only patch to apply: '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'
(http://marc.info/?l=linux-omap&m=129535214414192&w=2) which depends on Dave Martin's ([PATCH v4] ARM: Thumb-2: Symbol manipulation macros for function body copying'
(http://marc.info/?l=linux-omap&m=129503990527072&w=2).

Is this enough? If not I can have them in a branch of a gitorious tree.

Quoted 3 lines

Tony

Thanks,
Jean

Tony Lindgren

2011-01-19 21:44 UTC #13 lore raw

PATCH 1/1 OMAP: use fncpy to copy the PM code functions to SRAM

Quoted 39 lines · Jean Pihet

Hi Tony,
Quoted 31 lines · Tony Lindgren
Quoted 30 lines · Jean Pihet
Quoted 18 lines · Tony Lindgren
Quoted 17 lines · Russell King - ARM Linux
Quoted 16 lines · Jean Pihet
Dave, Russell,
Quoted 10 lines · Dave Martin
One way to work around this is would be to make omap_sram_push() a macro:
#define omap_sram_push(funcp, size) \
? ?(typeof(funcp))_do_omap_sram_push((void *)(funcp), size)
... where the definition of _do_omap_sram_push() is the same is the existing definition of omap_sram_push(). ?Providing _do_omap_sram_push() is not called directly, this should now be type-safe.
Ok I reworked the patch from your suggestions. Indeed a few functions types mismatch have been spotted and corrected using the fncpy API.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
New patch sent as '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'.
Looks good, thanks. ?Next problem to sort out is who's taking the patches...
You can take them but we should have at least Kevin test and ack them.
Sure, this needs some testing on OMAP1 & 2 platforms. It has only been compile tested on those (means: compile OK, functions types mismatches fixed).
Quoted 5 lines
Quoted 1 line
Anyone with OMAP1 & 2 boards willing to test?
Can you please repost the whole set one more time or have them in some git branch? That way I can pull them into linux-omap master branch for testing to make sure omap1 and 2 boards don't break.

Quoted 8 lines

There is only patch to apply: '[PATCH v2] OMAP: use fncpy to copy the PM code functions to SRAM'
(http://marc.info/?l=linux-omap&m=129535214414192&w=2) which depends on Dave Martin's ([PATCH v4] ARM: Thumb-2: Symbol manipulation macros for function body copying'
(http://marc.info/?l=linux-omap&m=129503990527072&w=2).
Is this enough? If not I can have them in a branch of a gitorious tree.

OK, will apply them into omap-testing. Then hopefully within next few days Russell can set up some immutable branch that we can merge too as some PM patches may conflict with these.

Regards,

Tony