Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff.
the flush MUST NOT be soc specific as there is NO need to do this at all
so NACK
Let's summarize:
- First, you NACK because of device_type and function name
- Then, you mention "this code is omap3 specific"
- Then, you mention "this code is not needed at all"
the current implementation is wrong
there is NO NEED to have a omap3 specific full cache code as the generic armv7 full cache work fine on omap3
that's why rename it or move it make no sense as we can use the same full cache code on cortex a8
the only part that could be soc specific will the l2 flush code
that's why I NACK this as it does not fix anything and just will end with duplicated code
and yes I do want to have armv7 name in the armv cache function
I known you will tell but the other does not I agree the other arm flush code need to be clean and it's plan anyway as I need it to add the mmu and d-cache support which will be done later
As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. Then everybody (including you) can send additional patches for further improvements.
It's plan as I'm working currentlty on the mmu and d-cache support for arm and the current arm implementation will be udpated really soon to allow this and after I'll take a look in the relocation scheme on arm
Best Regards, J.