On Wed, Jan 19, 2011 at 12:44 AM, Tony Lindgren <[email protected]> wrote: > * Russell King - ARM Linux <[email protected]> [110118 15:41]: >> On Tue, Jan 18, 2011 at 01:05:49PM +0100, Jean Pihet wrote: >> > Dave, Russell, >> > >> > On Mon, Jan 17, 2011 at 4:46 PM, Dave Martin <[email protected]> >> > wrote: >> > > 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. >> > >> > 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 > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
