On Tue, Oct 20, 2015 at 01:26:55AM +0200, Arnaud Ebalard wrote: > Hi Russell, > > Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html