On Tue, Oct 20, 2015 at 01:26:55AM +0200, Arnaud Ebalard wrote:
> Hi Russell,
>
> Russell King <[email protected]> writes:
>
> > Use the IO memcpy() functions when copying from/to MMIO memory.
> > These locations were found via sparse.
>
> On recent MVEBU hardware, *_std_* function are not expected to be used
> because we will instead use the TDMA-based versions. So the only
> possible penalty we could get (if any) from this change on recent
> devices is for the copy of the IV in mv_cesa_ablkcipher_process(). Out
> of curiosity, I took a quick look at what is generated and it seems this
> results in a call to mmiocpy():
>
> 00000340 <mv_cesa_ablkcipher_process>:
> 340: e1a0c00d mov ip, sp
> 344: e92dd830 push {r4, r5, fp, ip, lr, pc}
> 348: e24cb004 sub fp, ip, #4
> 34c: e24dd008 sub sp, sp, #8
>
> ....
>
> 3a4: e5943010 ldr r3, [r4, #16]
> 3a8: e5951008 ldr r1, [r5, #8]
> 3ac: e594001c ldr r0, [r4, #28]
> 3b0: e2811040 add r1, r1, #64 ; 0x40
> 3b4: e593201c ldr r2, [r3, #28]
> 3b8: ebfffffe bl 0 <mmiocpy>
>
> which if I am not mistaken is provided by arch/arm/lib/memcpy.S via:
>
> ENTRY(mmiocpy)
> ENTRY(memcpy)
>
> #include "copy_template.S"
>
> ENDPROC(memcpy)
> ENDPROC(mmiocpy)
>
> Am I right in concluding this will end up being the code of a usual
> memcpy(), i.e. the change is a noop in the final code compared to
> previous version?
Almost - what's different is the compiler is not allowed to "optimise"
this memcpy call. See 1bd46782d08b ("ARM: avoid unwanted GCC
memset()/memcpy() optimisations for IO variants")
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
