{"push_id":591455174,"size":28,"distinct_size":28,"ref":"refs/heads/cm-12.0","head":"eec7b6031223745174d3c069c29cefa4304804e6","before":"769d1e1cf8bd7645bdcdb89dde2cfb3be5d36038","commits":[{"sha":"691434946e1b041ef56b7d73f709f52e04616243","author":{"email":"d77b46f71ad07d1c66a004715c9110750816d270@motorola.com","name":"Jason Hrycay"},"message":"msm: memutils: memcpy, memmove, copy_page optimization\n\nPreload farther to take advantage of the memory bus, and assume\n64-byte cache lines.  Unroll some pairs of ldm/stm as well, for\nunexplainable reasons.\n\nFuture enhancements should include,\n\n- #define for how far to preload, possibly defined separately for\n  memcpy, copy_*_user\n- Tuning for misaligned buffers\n- Tuning for memmove\n- Tuning for small buffers\n- Understanding mechanism behind ldm/stm unroll causing some gains\n  in copy_to_user\n\nBASELINE (msm8960pro):\n======================================================================\nmemcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s\ncopy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s\ncopy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s\nmemmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s\ncopy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s\ncopy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s\ncopy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s\n\nTHIS PATCH:\n======================================================================\nmemcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s\ncopy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s\ncopy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s\nmemmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s\ncopy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s\ncopy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s\ncopy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s\n\nSigned-off-by: Chris Fries <C.Fries@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\n\nConflicts:\n\tarch/arm/lib/Makefile\n\tarch/arm/mach-msm/Kconfig\n\tarch/arm/mach-msm/Makefile\n\nChange-Id: Ief4ee892e226b77878790af69acbacb6836fa333","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/691434946e1b041ef56b7d73f709f52e04616243"},{"sha":"a06b3c89d7c3086009226b1b8fff4355139de939","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"arm: lib: Fix makefile bug\n\nWhen HAS_MACH_MEMUTILS is defined, two version of memcpy.S would\nbe built at the same time, fix the issue here.\n\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/a06b3c89d7c3086009226b1b8fff4355139de939"},{"sha":"7217bada4535478fcd8788c87d0d0c88a2a3c668","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"msm: memutils: memcpy, memmove optimization\n\n1. To fit 8x26 64-bytes cache line size, we change preload steps as 64Bytes.\n2. According to tune result, change preload distance as 5 cache lines.\n3. According to tune result, re-arrange the ld/str order as back-to-back\n   for copy_from_user.\n\nThe markable improvement:\n\tmemcpy : 5%\n\tcopy_to_user : 9%\n\tcopy_from_user : 13%\n\tmemmove : 37%\n\nRaw data is as below:\n\nBASELINE:\n\tmemcpy 1000MB at 5MB       : took 1547098 usec, bandwidth 646.646 MB/s\n\tcopy_to_user 1000MB at 5MB : took 1704308 usec, bandwidth 586.586 MB/s\n\tcopy_from_user 1000MB at 5M: took 1777090 usec, bandwidth 562.562 MB/s\n\tmemmove 1000GB at 5MB      : took 1066205 usec, bandwidth 937.937 MB/s\n\tcopy_to_user 1000GB at 4kB : took 1774866 usec, bandwidth 563.563 MB/s\n\tcopy_from_user 1000GB at 4k: took 1797654 usec, bandwidth 556.556 MB/s\n\tcopy_page 1000GB at 4kB    : took 1644606 usec, bandwidth 608.608 MB/s\n\tmemmove 1000GB at 4kB      : took 1236227 usec, bandwidth 808.808 MB/s\n\nTHIS PATCH:\n\tmemcpy 1000MB at 5MB       : took 1475835 usec, bandwidth 677.677 MB/s\n\tcopy_to_user 1000MB at 5MB : took 1559060 usec, bandwidth 641.641 MB/s\n\tcopy_from_user 1000MB at 5M: took 1561603 usec, bandwidth 640.640 MB/s\n\tmemmove 1000GB at 5MB      : took 861664 usec, bandwidth 1160.160 MB/s\n\tcopy_to_user 1000GB at 4kB : took 1673501 usec, bandwidth 597.597 MB/s\n\tcopy_from_user 1000GB at 4k: took 1674006 usec, bandwidth 597.597 MB/s\n\tcopy_page 1000GB at 4kB    : took 1691358 usec, bandwidth 591.591 MB/s\n\tmemmove 1000GB at 4kB      : took 882985 usec, bandwidth 1132.132 MB/s\n\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nSLT-Approved: Slta Waiver <sltawvr@motorola.com>\nReviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>\nReviewed-by: Check Patch <CHEKPACH@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/7217bada4535478fcd8788c87d0d0c88a2a3c668"},{"sha":"f35d295abd6346036187de3c2676251d74936a5c","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"msm: memutils: memcpy, memmove optimization\n\nAccording to tune result, change preload distance to 10 cacheline on 8084.\n\nFor large memory access, the speed could be doubled.\nFor small memory access, the speed is also improved alot or equal at least.\n\nRaw data is as below:\n\nBEFORE:\n\tmemcpy 1000MB at 5MB       : took 680486 usec, bw 1469.469 MB/s\n\tcopy_to_user 1000MB at 5MB : took 610000 usec, bw 1639.639 MB/s\n\tcopy_from_user 1000MB at 5M: took 713548 usec, bw 1401.401 MB/s\n\tmemmove 1000GB at 5MB      : took 660684 usec, bw 1513.513 MB/s\n\tcopy_to_user 1000GB at 4kB : took 622890 usec, bw 1605.605 MB/s\n\tcopy_from_user 1000GB at 4k: took 656338 usec, bw 1523.523 MB/s\n\tcopy_page 1000GB at 4kB    : took 663905 usec, bw 1506.506 MB/s\n\tmemmove 1000GB at 4kB      : took 654784 usec, bw 1527.527 MB/s\n\tmemcpy 1000MB at 1kB : took 703693 usec, bw 1421.421 MB/s\n\tcopy_to_user 1000MB at 1kB : took 703283 usec, bw 1421.421 MB/s\n\tcopy_from_user 1000MB at 1k: took 719249 usec, bw 1390.390 MB/s\n\tcopy_page 1000MB at 1kB    : took 1013640 usec, bw 986.986 MB/s\n\tmemmove 1000MB at 1kB      : took 657677 usec, bw 1520.520 MB/s\n\tmemcpy 1000MB at 512B : took 779628 usec, bw 1282.282 MB/s\n\tcopy_to_user 1000MB at 512B : took 785778 usec, bw 1272.272 MB/s\n\tcopy_from_user 1000MB at 512B: took 785235 usec, bw 1273.273 MB/\n\tcopy_page 1000MB at 512B    : took 1532921 usec, bw 652.652 MB/s\n\tmemmove 1000MB at 512B      : took 657164 usec, bw 1521.521 MB/s\n\tmemcpy 1000MB at 64B : took 1683479 usec, bw 594.594 MB/s\n\tcopy_to_user 1000MB at 64B : took 1482090 usec, bw 674.674 MB/s\n\tcopy_from_user 1000MB at 64B: took 1469437 usec, bw 680.680 MB/s\n\tcopy_page 1000MB at 64B    : took 2153816 usec, bw 464.464 MB/s\n\tmemmove 1000MB at 64B      : took 1380364 usec, bw 724.724 MB/s\n\nAFTER:\n\tmemcpy 1000MB at 5MB       : took 354406 usec, bw 2821.821 MB/s\n\tcopy_to_user 1000MB at 5MB : took 379733 usec, bw 2633.633 MB/s\n\tcopy_from_user 1000MB at 5M: took 378422 usec, bw 2642.642 MB/s\n\tmemmove 1000GB at 5MB      : took 258310 usec, bw 3871.871 MB/s\n\tcopy_to_user 1000GB at 4kB : took 391266 usec, bw 2555.555 MB/s\n\tcopy_from_user 1000GB at 4k: took 431480 usec, bw 2317.317 MB/s\n\tcopy_page 1000GB at 4kB    : took 345506 usec, bw 2894.894 MB/s\n\tmemmove 1000GB at 4kB      : took 274865 usec, bw 3638.638 MB/s\n\tmemcpy 1000MB at 1kB : took 496271 usec, bw 2015.015 MB/s\n\tcopy_to_user 1000MB at 1kB : took 476588 usec, bw 2098.098 MB/s\n\tcopy_from_user 1000MB at 1k: took 431087 usec, bw 2319.319 MB/s\n\tcopy_page 1000MB at 1kB    : took 659923 usec, bw 1515.515 MB/s\n\tmemmove 1000MB at 1kB      : took 338365 usec, bw 2955.955 MB/s\n\tmemcpy 1000MB at 512B : took 501346 usec, bw 1994.994 MB/s\n\tcopy_to_user 1000MB at 512B : took 620348 usec, bw 1611.611 MB/s\n\tcopy_from_user 1000MB at 512B: took 617315 usec, bw 1619.619 MB/s\n\tcopy_page 1000MB at 512B    : took 1097686 usec, bw 911.911 MB/s\n\tmemmove 1000MB at 512B      : took 453838 usec, bw 2203.203 MB/s\n\tmemcpy 1000MB at 64B : took 1718396 usec, bw 581.581 MB/s\n\tcopy_to_user 1000MB at 64B : took 1593446 usec, bw 627.627 MB/s\n\tcopy_from_user 1000MB at 64B: took 1610274 usec, bw 621.621 MB/s\n\tcopy_page 1000MB at 64B    : took 475142 usec, bw 2104.104 MB/s\n\tmemmove 1000MB at 64B      : took 1382806 usec, bw 723.723 MB/s\n\nChange-Id: Iecadbf795d08da0cbb944622b6bc5af924f291f0\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nReviewed-by: John Zafiris <johnz@motorola.com>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/f35d295abd6346036187de3c2676251d74936a5c"},{"sha":"4480f8b5f1476a5e65b305d3615e4ee9b0565f5b","author":{"email":"ad5ede63337b3f6ba0c8f4353e50bd01ded91d63@gmail.com","name":"Dan Pasanen"},"message":"defconfig: g3: enable Motorola's MSM memcpy enhancements\n\nChange-Id: I4850677a0ecde26219fe345c862151e976af8a85","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/4480f8b5f1476a5e65b305d3615e4ee9b0565f5b"},{"sha":"649bdb8133d5f49df71d1b25222b1e48058be258","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: move VFP init to an earlier boot stage\n\nIn order to use the NEON unit in the kernel, we should\ninitialize it a bit earlier in the boot process so NEON users\nthat like to do a quick benchmark at load time (like the\nxor_blocks or RAID-6 code) find the NEON/VFP unit already\nenabled.\n\nReplaced late_initcall() with core_initcall().\n\nChange-Id: I89b7a5a79dddf6083766a87f9d082c7ee61a54e0\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/649bdb8133d5f49df71d1b25222b1e48058be258"},{"sha":"ca53d25e54ca25df478574e01f6c3ea920e99ae9","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: be strict about FP exceptions in kernel mode\n\nThe support code in vfp_support_entry does not care whether the\nexception that caused it to be invoked occurred in kernel mode or\nin user mode. However, neither condition that could trigger this\nexception (lazy restore and VFP bounce to support code) is\ncurrently allowable in kernel mode.\n\nIn either case, print a message describing the condition before\nletting the undefined instruction handler run its course and trigger\nan oops.\n\nChange-Id: I1a9508f3adfb0264cac1984d6080d117bfcb39f6\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/ca53d25e54ca25df478574e01f6c3ea920e99ae9"},{"sha":"29417491e7cadcb306b94ad0724e85aaa2a0fbbe","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: add support for kernel mode NEON\n\nIn order to safely support the use of NEON instructions in\nkernel mode, some precautions need to be taken:\n- the userland context that may be present in the registers (even\n  if the NEON/VFP is currently disabled) must be stored under the\n  correct task (which may not be 'current' in the UP case),\n- to avoid having to keep track of additional vfpstates for the\n  kernel side, disallow the use of NEON in interrupt context\n  and run with preemption disabled,\n- after use, re-enable preemption and re-enable the lazy restore\n  machinery by disabling the NEON/VFP unit.\n\nThis patch adds the functions kernel_neon_begin() and\nkernel_neon_end() which take care of the above. It also adds\nthe Kconfig symbol KERNEL_MODE_NEON to enable it.\n\nChange-Id: Iddde22ad8684e92e5f0aa4999962ad743eff8f7c\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\n\nConflicts:\n\tarch/arm/vfp/vfpmodule.c","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/29417491e7cadcb306b94ad0724e85aaa2a0fbbe"},{"sha":"1fbf3563bdde66a9d8f81414df35d2d6c84537df","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: crypto: add NEON accelerated XOR implementation\n\nAdd a source file xor-neon.c (which is really just the reference\nC implementation passed through the GCC vectorizer) and hook it\nup to the XOR framework.\n\nChange-Id: If251e5a16d628ddfdd8d6ce40b78014cd2962d7e\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/1fbf3563bdde66a9d8f81414df35d2d6c84537df"},{"sha":"665621dd1dd0d7989a09b0aac3b7b06efc15ea11","author":{"email":"5ef2a23ba3aff51d1cfc8c113c1ec34b608b3b13@nvidia.com","name":"Stephen Warren"},"message":"ARM: 7780/1: add missing linker section markup to head-common.S\n\nMacro __INIT is used to place various code in head-common.S into the init\nsection. This should be matched by a closing __FINIT. Also, add an\nexplicit \".text\" to ensure subsequent code is placed into the correct\nsection; __FINIT is simply a closing marker to match __INIT and doesn't\nguarantee to revert to .text.\n\nThis historically caused no problem, because macro __CPUINIT was used at\nthe exact location where __FINIT was missing, which then placed following\ncode into the cpuinit section. However, with commit 22f0a2736 \"init.h:\nremove __cpuinit sections from the kernel\" applied, __CPUINIT becomes a\nno-op, thus leaving all this code in the init section, rather than the\nregular text section. This caused issues such as secondary CPU boot\nfailures or crashes.\n\nChange-Id: I2c346b58c4c4d50a162b19e9967d44ec5e97c7d4\nSigned-off-by: Stephen Warren <swarren@nvidia.com>\nAcked-by: Paul Gortmaker <paul.gortmaker@windriver.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/665621dd1dd0d7989a09b0aac3b7b06efc15ea11"},{"sha":"645b59fe03711a4b5da65379cda32bbe509d939e","author":{"email":"288a049a20dc4091188b72022d411ad1375e6737@gmail.com","name":"Fabio Estevam"},"message":"ARM: 7782/1: Kconfig: Let ARM_ERRATA_364296 not depend on CONFIG_SMP\n\nimx_v6_v7_defconfig handles both multi-core and single-core SoCs, and it has CONFIG_SMP=y selected by default.\n\nWith such config we cannot select ARM_ERRATA_364296, as it depends on !SMP.\n\nLet ARM_ERRATA_364296 be undependent on CONFIG_SMP, so that we can select this erratum for the ARM1136 SoCs, even if CONFIG_SMP=y is enabled.\n\nChange-Id: Ia96ea3d8e9468884962793cc4a6b19f62e1adc59\nReviewed-by: Dave Martin <Dave.Martin@arm.com>\nSigned-off-by: Fabio Estevam <fabio.estevam@freescale.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/645b59fe03711a4b5da65379cda32bbe509d939e"},{"sha":"5aee4ffcd36e5246ef9bfb762abc1dd2ddab184f","author":{"email":"380081620a7947c89c11153c5513f34019caa923@android.com","name":"Colin Cross"},"message":"ARM: ftrace: Trace function entry before updating index\n\nCommit 722b3c74695377d11d18a52f3da08114d37f3f37 modified x86 ftrace to\navoid tracing all functions called from irqs when function graph was\nused with a filter.  Port the same fix to ARM.\n\nChange-Id: I3facbb85447effe54ff92db206068087c892fc28\nSigned-off-by: Colin Cross <ccross@android.com>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/5aee4ffcd36e5246ef9bfb762abc1dd2ddab184f"},{"sha":"e99bab70a6ac767d1e15f886850695de64056636","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"crypto: create generic version of ablk_helper\n\nCreate a generic version of ablk_helper so it can be reused\nby other architectures.\n\nAcked-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\n\nConflicts:\n\tcrypto/Kconfig\n\tcrypto/Makefile\n\nChange-Id: I01a0d1192383c9a0287590a2cef1424e4675c531","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/e99bab70a6ac767d1e15f886850695de64056636"},{"sha":"cdb5f1828c08bf3fa5b788406677da0a396f6104","author":{"email":"24f7fe9d205c8a9f6ade0c2894e14303ca16087f@intel.com","name":"kbuild test robot"},"message":"crypto: ablk_helper - Replace memcpy with struct assignment\n\ntree:   git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master\nhead:   48e6dc1b2a1ad8186d48968d5018912bdacac744\ncommit: a62b01cd6cc1feb5e80d64d6937c291473ed82cb [20/24] crypto: create generic version of ablk_helper\n\ncoccinelle warnings: (new ones prefixed by >>)\n\n>> crypto/ablk_helper.c:97:2-8: Replace memcpy with struct assignment\n>> crypto/ablk_helper.c:78:2-8: Replace memcpy with struct assignment\n\nPlease consider folding the attached diff :-)\n\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/cdb5f1828c08bf3fa5b788406677da0a396f6104"},{"sha":"fc4d6213597d106afdf1510ca037d7077a931497","author":{"email":"1e3ed3bf048787d5836c6bf2eaa8f3a7c1b27ef4@mcafee.com","name":"David McCullough"},"message":"arm/crypto: Add optimized AES and SHA1 routines\n\nAdd assembler versions of AES and SHA1 for ARM platforms.  This has provided\nup to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.\n\nPlatform   CPU SPeed    Endian   Before (bps)   After (bps)   Improvement\n\nIXP425      533 MHz      big     11217042        15566294        ~38%\nKS8695      166 MHz     little    3828549         5795373        ~51%\n\nSigned-off-by: David McCullough <ucdevel@gmail.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/fc4d6213597d106afdf1510ca037d7077a931497"},{"sha":"5bb553f54e63670d2dc137b519ea6111765daee6","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: move AES typedefs and function prototypes to separate header\n\nPut the struct definitions for AES keys and the asm function prototypes in a\nseparate header and export the asm functions from the module.\nThis allows other drivers to use them directly.\n\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/5bb553f54e63670d2dc137b519ea6111765daee6"},{"sha":"0beef0177e0f6f1c1727d44c18c60b5a01da20fb","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: add support for bit sliced AES using NEON instructions\n\nBit sliced AES gives around 45% speedup on Cortex-A15 for encryption\nand around 25% for decryption. This implementation of the AES algorithm\ndoes not rely on any lookup tables so it is believed to be invulnerable\nto cache timing attacks.\n\nThis algorithm processes up to 8 blocks in parallel in constant time. This\nmeans that it is not usable by chaining modes that are strictly sequential\nin nature, such as CBC encryption. CBC decryption, however, can benefit from\nthis implementation and runs about 25% faster. The other chaining modes\nimplemented in this module, XTS and CTR, can execute fully in parallel in\nboth directions.\n\nThe core code has been adopted from the OpenSSL project (in collaboration\nwith the original author, on cc). For ease of maintenance, this version is\nidentical to the upstream OpenSSL code, i.e., all modifications that were\nrequired to make it suitable for inclusion into the kernel have been made\nupstream. The original can be found here:\n\n    http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130\n\nNote to integrators:\nWhile this implementation is significantly faster than the existing table\nbased ones (generic or ARM asm), especially in CTR mode, the effects on\npower efficiency are unclear as of yet. This code does fundamentally more\nwork, by calculating values that the table based code obtains by a simple\nlookup; only by doing all of that work in a SIMD fashion, it manages to\nperform better.\n\nCc: Andy Polyakov <appro@openssl.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/0beef0177e0f6f1c1727d44c18c60b5a01da20fb"},{"sha":"bc46ac05760c19688bd887cf8770ecc33aac866b","author":{"email":"f6aa0246ff943bfa8602cdf60d40c481b38ed232@arm.linux.org.uk","name":"Russell King"},"message":"ARM: add .gitignore entry for aesbs-core.S\n\nThis avoids this file being incorrectly added to git.\n\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/bc46ac05760c19688bd887cf8770ecc33aac866b"},{"sha":"1518ed830731e39e354b3c12016e90670a63feca","author":{"email":"f6aa0246ff943bfa8602cdf60d40c481b38ed232@arm.linux.org.uk","name":"Russell King"},"message":"CRYPTO: Fix more AES build errors\n\nBuilding a multi-arch kernel results in:\n\narch/arm/crypto/built-in.o: In function `aesbs_xts_decrypt':\nsha1_glue.c:(.text+0x15c8): undefined reference to `bsaes_xts_decrypt'\narch/arm/crypto/built-in.o: In function `aesbs_xts_encrypt':\nsha1_glue.c:(.text+0x1664): undefined reference to `bsaes_xts_encrypt'\narch/arm/crypto/built-in.o: In function `aesbs_ctr_encrypt':\nsha1_glue.c:(.text+0x184c): undefined reference to `bsaes_ctr32_encrypt_blocks'\narch/arm/crypto/built-in.o: In function `aesbs_cbc_decrypt':\nsha1_glue.c:(.text+0x19b4): undefined reference to `bsaes_cbc_encrypt'\n\nThis code is already runtime-conditional on NEON being supported, so\nthere's no point compiling it out depending on the minimum build\narchitecture.\n\nAcked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/1518ed830731e39e354b3c12016e90670a63feca"},{"sha":"660a213fce2f6d75bf7966e5955dc7ea1eca87b8","author":{"email":"52f8f9962b7f38d8269c63c0859d68147c8d10f0@redhat.com","name":"Mikulas Patocka"},"message":"crypto: arm-aes - fix encryption of unaligned data\n\nFix the same alignment bug as in arm64 - we need to pass residue\nunprocessed bytes as the last argument to blkcipher_walk_done.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nCc: stable@vger.kernel.org\t# 3.13+\nAcked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/777jon/g3_kernel/commits/660a213fce2f6d75bf7966e5955dc7ea1eca87b8"}]}