GitHub PushEvent at 2014-10-04 18:37:40
Repository: kernel_htc_msm8974
Actor: PRJosh
Payload: {"shas":[["70077427f257ef2e8c4c422cf50514527306b01a","f29209e176deba8cfd2e79bb6b9166c7d43dc10b@lge.com","crypto: Add lz4 Cryptographic API\n\nFrom\tChanho Min <>\n\nThis patch adds support for lz4 and lz4hc compression algorithm\nusing the lib/lz4/* codebase.\nSigned-off-by: Chanho Min <chanho.min@lge.com>\n\nChange-Id: Ie0869e531e0269a74eb0352bb8623fc9f4bd0434\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Chanho Min",true],["31855c0a1598ec6e7a8eab4dd95a73730b888d00","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","lib/lz4/lz4_compress: fix macro usage error\n\nChange-Id: I21b723b49892705be5f7fc2f45d3ed0684ff9d77\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul Reioux",true],["3dfbf9b0591f859a5665e4339b25dbdcd726d27f","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","lib/memcopy: use glibc version\n\nthe kernel's memcpy and memmove is very inefficient. But the glibc version is\nquite fast, in some cases it is 10 times faster than the kernel version. So I\nintroduce some memory copy macros and functions of the glibc to improve the\nkernel version's performance.\n\nThe strategy of the memory functions is:\n1. Copy bytes until the destination pointer is aligned.\n2. Copy words in unrolled loops.  If the source and destination are not\n   aligned in the same way, use word memory operations, but shift and merge\n   two read words before writing.\n3. Copy the few remaining bytes.\n\nChange-Id: Id72773500954e85a2900c44e9f01a8b5ed390288\nSigned-off-by: Miao Xie <miaox*******>\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["f63445a5ce40fb71cf63b8e95751906fda2e63d1","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","lib/string: use glibc version\n\nthe performance of memcpy and memmove of the general version is very\ninefficient, this patch improved them.\n\nChange-Id: I4dc76750e85127469e37bafc8908d25e1d9716d6\nSigned-off-by: Miao Xie <miaox*******>\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["b8870c95856ef7148b365ad3b63cb20ba9112b41","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","Optimized ARM RWSEM algorithm\n\nRWSEM implementation for ARM using atomic functions.\nHeavily based on arch/sh/include/asm/rwsem.h\n\nChange-Id: I3bb0972c3b55cb3e882786de3f04886fa7243046\nSigned-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>","faux123",true],["13bd810375b449ce1ee9b54ab116bee5feceb490","1abc5746028550adcf7742cb5d47df86766285d8@intel.com","rwsem: Implement writer lock-stealing for better scalability\n\nCommit 5a505085f043 (\"mm/rmap: Convert the struct anon_vma::mutex\nto an rwsem\") changed struct anon_vma::mutex to an rwsem, which\ncaused aim7 fork_test performance to drop by 50%.\n\nYuanhan Liu did the following excellent analysis:\n\n    https://lkml.org/lkml/2013/1/29/84\n\nand found that the regression is caused by strict, serialized,\nFIFO sequential write-ownership of rwsems. Ingo suggested\nimplementing opportunistic lock-stealing for the front writer\ntask in the waitqueue.\n\nYuanhan Liu implemented lock-stealing for spinlock-rwsems,\nwhich indeed recovered much of the regression - confirming\nthe analysis that the main factor in the regression was the\nFIFO writer-fairness of rwsems.\n\nIn this patch we allow lock-stealing to happen when the first\nwaiter is also writer. With that change in place the\naim7 fork_test performance is fully recovered on my\nIntel NHM EP, NHM EX, SNB EP 2S and 4S test-machines.\n\nReported-by: lkp@linux.intel.com\nReported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>\nSigned-off-by: Alex Shi <alex.shi@intel.com>\nCc: David Howells <dhowells@redhat.com>\nCc: Michel Lespinasse <walken@google.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Peter Zijlstra <a.p.zijlstra@chello.nl>\nCc: Anton Blanchard <anton@samba.org>\nCc: Arjan van de Ven <arjan@linux.intel.com>\nCc: paul.gortmaker@windriver.com\nLink: https://lkml.org/lkml/2013/1/29/84\nLink: http://lkml.kernel.org/r/1360069915-31619-1-git-send-email-alex.shi@intel.com\n[ Small stylistic fixes, updated changelog. ]\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nChange-Id: Ie02f9f2821043159b3a59f537cb5b63806da9c7f\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Alex Shi",true],["4ec086a74667c7555da99d60462047bffebe1126","5dcef21195e64c9c08aa779bb62b25e9133eaa33@linux.intel.com","rwsem-spinlock: Implement writer lock-stealing for better scalability\n\nWe (Linux Kernel Performance project) found a regression\nintroduced by commit:\n\n  5a505085f043 mm/rmap: Convert the struct anon_vma::mutex to an rwsem\n\nwhich converted all anon_vma::mutex locks rwsem write locks.\n\nThe semantics are the same, but the behavioral difference is\nquite huge in some cases. After investigating it we found the\nroot cause: mutexes support lock stealing while rwsems don't.\n\nHere is the link for the detailed regression report:\n\n  https://lkml.org/lkml/2013/1/29/84\n\nIngo suggested adding write lock stealing to rwsems:\n\n    \"I think we should allow lock-steal between rwsem writers - that\n     will not hurt fairness as most rwsem fairness concerns relate to\n     reader vs. writer fairness\"\n\nAnd here is the rwsem-spinlock version.\n\nWith this patch, we got a double performance increase in one\ntest box with following aim7 workfile:\n\n    FILESIZE: 1M\n    POOLSIZE: 10M\n    10 fork_test\n\n /usr/bin/time output w/o patch                       /usr/bin/time_output with patch\n -- Percent of CPU this job got: 369%                 Percent of CPU this job got: 537%\n Voluntary context switches: 640595016                Voluntary context switches: 157915561\n\nWe got a 45% increase in CPU usage and saved about 3/4 voluntary context switches.\n\nChange-Id: I77d31bd51369f43690949ad9f56149b39aa411c5\nReported-by: LKP project <lkp@linux.intel.com>\nSuggested-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>\nCc: Alex Shi <alex.shi@intel.com>\nCc: David Howells <dhowells@redhat.com>\nCc: Michel Lespinasse <walken@google.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Peter Zijlstra <a.p.zijlstra@chello.nl>\nCc: Anton Blanchard <anton@samba.org>\nCc: Arjan van de Ven <arjan@linux.intel.com>\nCc: paul.gortmaker@windriver.com\nLink: http://lkml.kernel.org/r/1359716356-23865-1-git-send-email-yuanhan.liu@linux.intel.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Yuanhan Liu",true],["27d3223cc2f2c77cfad787558bfa6590e85e26c3","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","lib: Sparc's strncpy_from_user is generic enough, move under lib/\n\nTo use this, an architecture simply needs to:\n\n1) Provide a user_addr_max() implementation via asm/uaccess.h\n\n2) Add \"select GENERIC_STRNCPY_FROM_USER\" to their arch Kcnfig\n\n3) Remove the existing strncpy_from_user() implementation and symbol\n   exports their architecture had.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nAcked-by: David Howells <dhowells@redhat.com>\nadapted for Mako from kernel.org reference\n\nChange-Id: I1a59e46127f10c6c786d71a84ab2df88de7aff7d\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul Reioux",true],["d8f177fb8a7eaba7ab5532a379f6d2dec982976d","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","word-at-a-time: make the interfaces truly generic\n\nThis changes the interfaces in <asm/word-at-a-time.h> to be a bit more\ncomplicated, but a lot more generic.\n\nIn particular, it allows us to really do the operations efficiently on\nboth little-endian and big-endian machines, pretty much regardless of\nmachine details.  For example, if you can rely on a fast population\ncount instruction on your architecture, this will allow you to make your\noptimized <asm/word-at-a-time.h> file with that.\n\nNOTE! The \"generic\" version in include/asm-generic/word-at-a-time.h is\nnot truly generic, it actually only works on big-endian.  Why? Because\non little-endian the generic algorithms are wasteful, since you can\ninevitably do better. The x86 implementation is an example of that.\n\n(The only truly non-generic part of the asm-generic implementation is\nthe \"find_zero()\" function, and you could make a little-endian version\nof it.  And if the Kbuild infrastructure allowed us to pick a particular\nheader file, that would be lovely)\n\nThe <asm/word-at-a-time.h> functions are as follows:\n\n - WORD_AT_A_TIME_CONSTANTS: specific constants that the algorithm\n   uses.\n\n - has_zero(): take a word, and determine if it has a zero byte in it.\n   It gets the word, the pointer to the constant pool, and a pointer to\n   an intermediate \"data\" field it can set.\n\n   This is the \"quick-and-dirty\" zero tester: it's what is run inside\n   the hot loops.\n\n - \"prep_zero_mask()\": take the word, the data that has_zero() produced,\n   and the constant pool, and generate an *exact* mask of which byte had\n   the first zero.  This is run directly *outside* the loop, and allows\n   the \"has_zero()\" function to answer the \"is there a zero byte\"\n   question without necessarily getting exactly *which* byte is the\n   first one to contain a zero.\n\n   If you do multiple byte lookups concurrently (eg \"hash_name()\", which\n   looks for both NUL and '/' bytes), after you've done the prep_zero_mask()\n   phase, the result of those can be or'ed together to get the \"either\n   or\" case.\n\n - The result from \"prep_zero_mask()\" can then be fed into \"find_zero()\"\n   (to find the byte offset of the first byte that was zero) or into\n   \"zero_bytemask()\" (to find the bytemask of the bytes preceding the\n   zero byte).\n\n   The existence of zero_bytemask() is optional, and is not necessary\n   for the normal string routines.  But dentry name hashing needs it, so\n   if you enable DENTRY_WORD_AT_A_TIME you need to expose it.\n\nThis changes the generic strncpy_from_user() function and the dentry\nhashing functions to use these modified word-at-a-time interfaces.  This\ngets us back to the optimized state of the x86 strncpy that we lost in\nthe previous commit when moving over to the generic version.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tfs/namei.c\n\nConflicts:\n\n\tfs/namei.c\n\nChange-Id: I30e840420fbf646b2d0a5d251c5592495135a4f9","faux123",true],["0287be297a5a3d421684c77789e0c42d80e1a728","69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","lib: add generic strnlen_user() function\n\nThis adds a new generic optimized strnlen_user() function that uses the\n<asm/word-at-a-time.h> infrastructure to portably do efficient string\nhandling.\n\nIn many ways, strnlen is much simpler than strncpy, and in particular we\ncan always pre-align the words we load from memory.  That means that all\nthe worries about alignment etc are a non-issue, so this one can easily\nbe used on any architecture.  You obviously do have to do the\nappropriate word-at-a-time.h macros.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nChange-Id: I2d53dc4016e96a08475580ed809991758cb3f6ec\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Linus Torvalds",true],["0ffd100a7e810f268236d9105a318b2c8d80e979","19a0ba370c443ba08d20b5061586430ab449ee8c@samba.org","lib: Fix generic strnlen_user for 32-bit big-endian machines\n\nThe aligned_byte_mask() definition is wrong for 32-bit big-endian\nmachines: the \"7-(n)\" part of the definition assumes a long is 8\nbytes.  This fixes it by using BITS_PER_LONG - 8 instead of 8*7.\nTested on 32-bit and 64-bit PowerPC.\n\nChange-Id: Ieaa8d1bc95f3d1c9543793b957fd0d649d2cff59\nSigned-off-by: Paul Mackerras <paulus@samba.org>\nAcked-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Paul Mackerras",true],["09e84f528e497f781c5c2264a7d36ba137ca2d3c","00bf0f20509cb3bd3255c624dba0f295e3c4128e@linaro.org","ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above\n\nModern GCC can generate code which makes use of the CPU's native\nunaligned memory access capabilities.  This is useful for the C\ndecompressor implementations used for unpacking compressed kernels.\n\nThis patch disables alignment faults and enables the v6 unaligned\naccess model on CPUs which support these features (i.e., v6 and\nlater), allowing full unaligned access support for C code in the\ndecompressor.\n\nThe decompressor C code must not be built to assume that unaligned\naccess works if support for v5 or older platforms is included in\nthe kernel.\n\nFor correct code generation, C decompressor code must always use\nthe get_unaligned and put_unaligned accessors when dealing with\nunaligned pointers, regardless of this patch.\n\nChange-Id: Iec57da876bb9ad84d015bb633adc2549e44e3743\nSigned-off-by: Dave Martin <dave.martin@linaro.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Dave Martin",true],["8bd00c3e4f095387cbac68325deedbf327bfbe1c","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","arch/arm/Kconfig: enable unaligned capability for ARM\n\nChange-Id: I7553c7a97e7fb0f07e0a95867df9b00583e10caf\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["039e743f3d22c92e18a1c138bf316ef95efcc3ae","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","ARM: use generic strnlen_user and strncpy_from_user functions\n\nThis patch implements the word-at-a-time interface for ARM using the\nsame algorithm as x86. We use the fls macro from ARMv5 onwards, where\nwe have a clz instruction available which saves us a mov instruction\nwhen targetting Thumb-2. For older CPUs, we use the magic 0x0ff0001\nconstant. Big-endian configurations make use of the implementation from\nasm-generic.\n\nWith this implemented, we can replace our byte-at-a-time strnlen_user\nand strncpy_from_user functions with the optimised generic versions.\n\nReviewed-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nmodified for Mako from LKML reference\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tarch/arm/Kconfig\n\nChange-Id: Id2e7b1fc54592c5b7c16239944cee614aa2393c0","Paul Reioux",true],["ab16b620e229e6453549c81d8cc521f5294fa43d","b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","ARM: dcache: select DCACHE_WORD_ACCESS for little-endian ARMv6+ CPUs\n\nDCACHE_WORD_ACCESS uses the word-at-a-time API for optimised string\ncomparisons in the vfs layer.\n\nThis patch implements support for load_unaligned_zeropad for ARM CPUs\nwith native support for unaligned memory accesses (v6+) when running\nlittle-endian.\n\nChange-Id: Ibdf40f90ee7a1c818d33f0ac5a656325322e0eb7\nReviewed-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Will Deacon <will.deacon@arm.com>","Will Deacon",true],["3486fa755697d83e9c2f4b1133fb38e2b362b7bf","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","ARM: 7493/1: use generic unaligned.h\n\nThis moves ARM over to the asm-generic/unaligned.h header. This has the\nbenefit of better code generated especially for ARMv7 on gcc 4.7+\ncompilers.\n\nAs Arnd Bergmann, points out: The asm-generic version uses the \"struct\"\nversion for native-endian unaligned access and the \"byteshift\" version\nfor the opposite endianess. The current ARM version however uses the\n\"byteshift\" implementation for both.\n\nThanks to Nicolas Pitre for the excellent analysis:\n\nTest case:\n\nint foo (int *x) { return get_unaligned(x); }\nlong long bar (long long *x) { return get_unaligned(x); }\n\nWith the current ARM version:\n\nfoo:\n\tldrb\tr3, [r0, #2]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]\n\tldrb\tr1, [r0, #1]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]\n\tldrb\tr2, [r0, #0]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]\n\tmov\tr3, r3, asl #16\t@ tmp154, MEM[(const u8 *)x_1(D) + 2B],\n\tldrb\tr0, [r0, #3]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]\n\torr\tr3, r3, r1, asl #8\t@, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],\n\torr\tr3, r3, r2\t@ tmp157, tmp155, MEM[(const u8 *)x_1(D)]\n\torr\tr0, r3, r0, asl #24\t@,, tmp157, MEM[(const u8 *)x_1(D) + 3B],\n\tbx\tlr\t@\n\nbar:\n\tstmfd\tsp!, {r4, r5, r6, r7}\t@,\n\tmov\tr2, #0\t@ tmp184,\n\tldrb\tr5, [r0, #6]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]\n\tldrb\tr4, [r0, #5]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]\n\tldrb\tip, [r0, #2]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]\n\tldrb\tr1, [r0, #4]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]\n\tmov\tr5, r5, asl #16\t@ tmp175, MEM[(const u8 *)x_1(D) + 6B],\n\tldrb\tr7, [r0, #1]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]\n\torr\tr5, r5, r4, asl #8\t@, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],\n\tldrb\tr6, [r0, #7]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]\n\torr\tr5, r5, r1\t@ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]\n\tldrb\tr4, [r0, #0]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]\n\tmov\tip, ip, asl #16\t@ tmp188, MEM[(const u8 *)x_1(D) + 2B],\n\tldrb\tr1, [r0, #3]\t@ zero_extendqisi2\t@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]\n\torr\tip, ip, r7, asl #8\t@, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],\n\torr\tr3, r5, r6, asl #24\t@,, tmp178, MEM[(const u8 *)x_1(D) + 7B],\n\torr\tip, ip, r4\t@ tmp191, tmp189, MEM[(const u8 *)x_1(D)]\n\torr\tip, ip, r1, asl #24\t@, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],\n\tmov\tr1, r3\t@,\n\torr\tr0, r2, ip\t@ tmp171, tmp184, tmp194\n\tldmfd\tsp!, {r4, r5, r6, r7}\n\tbx\tlr\n\nIn both cases the code is slightly suboptimal.  One may wonder why\nwasting r2 with the constant 0 in the second case for example.  And all\nthe mov's could be folded in subsequent orr's, etc.\n\nNow with the asm-generic version:\n\nfoo:\n\tldr\tr0, [r0, #0]\t@ unaligned\t@,* x\n\tbx\tlr\t@\n\nbar:\n\tmov\tr3, r0\t@ x, x\n\tldr\tr0, [r0, #0]\t@ unaligned\t@,* x\n\tldr\tr1, [r3, #4]\t@ unaligned\t@,\n\tbx\tlr\t@\n\nThis is way better of course, but only because this was compiled for\nARMv7. In this case the compiler knows that the hardware can do\nunaligned word access.  This isn't that obvious for foo(), but if we\nremove the get_unaligned() from bar as follows:\n\nlong long bar (long long *x) {return *x; }\n\nthen the resulting code is:\n\nbar:\n\tldmia\tr0, {r0, r1}\t@ x,,\n\tbx\tlr\t@\n\nSo this proves that the presumed aligned vs unaligned cases does have\ninfluence on the instructions the compiler may use and that the above\nunaligned code results are not just an accident.\n\nStill... this isn't fully conclusive without at least looking at the\nresulting assembly fron a pre ARMv6 compilation.  Let's see with an\nARMv5 target:\n\nfoo:\n\tldrb\tr3, [r0, #0]\t@ zero_extendqisi2\t@ tmp139,* x\n\tldrb\tr1, [r0, #1]\t@ zero_extendqisi2\t@ tmp140,\n\tldrb\tr2, [r0, #2]\t@ zero_extendqisi2\t@ tmp143,\n\tldrb\tr0, [r0, #3]\t@ zero_extendqisi2\t@ tmp146,\n\torr\tr3, r3, r1, asl #8\t@, tmp142, tmp139, tmp140,\n\torr\tr3, r3, r2, asl #16\t@, tmp145, tmp142, tmp143,\n\torr\tr0, r3, r0, asl #24\t@,, tmp145, tmp146,\n\tbx\tlr\t@\n\nbar:\n\tstmfd\tsp!, {r4, r5, r6, r7}\t@,\n\tldrb\tr2, [r0, #0]\t@ zero_extendqisi2\t@ tmp139,* x\n\tldrb\tr7, [r0, #1]\t@ zero_extendqisi2\t@ tmp140,\n\tldrb\tr3, [r0, #4]\t@ zero_extendqisi2\t@ tmp149,\n\tldrb\tr6, [r0, #5]\t@ zero_extendqisi2\t@ tmp150,\n\tldrb\tr5, [r0, #2]\t@ zero_extendqisi2\t@ tmp143,\n\tldrb\tr4, [r0, #6]\t@ zero_extendqisi2\t@ tmp153,\n\tldrb\tr1, [r0, #7]\t@ zero_extendqisi2\t@ tmp156,\n\tldrb\tip, [r0, #3]\t@ zero_extendqisi2\t@ tmp146,\n\torr\tr2, r2, r7, asl #8\t@, tmp142, tmp139, tmp140,\n\torr\tr3, r3, r6, asl #8\t@, tmp152, tmp149, tmp150,\n\torr\tr2, r2, r5, asl #16\t@, tmp145, tmp142, tmp143,\n\torr\tr3, r3, r4, asl #16\t@, tmp155, tmp152, tmp153,\n\torr\tr0, r2, ip, asl #24\t@,, tmp145, tmp146,\n\torr\tr1, r3, r1, asl #24\t@,, tmp155, tmp156,\n\tldmfd\tsp!, {r4, r5, r6, r7}\n\tbx\tlr\n\nCompared to the initial results, this is really nicely optimized and I\ncouldn't do much better if I were to hand code it myself.\n\nSigned-off-by: Rob Herring <rob.herring@calxeda.com>\nReviewed-by: Nicolas Pitre <nico@linaro.org>\nTested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>\nReviewed-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nmodified for Mako from kernel.org reference\n\nSigned-off-by: faux123 <reioux@gmail.com>\n\nConflicts:\n\tarch/arm/include/asm/unaligned.h\n\nConflicts:\n\n\tarch/arm/include/asm/unaligned.h\n\nChange-Id: I6317f96c161bf3d016c3353d2133f6146d9b1188","faux123",true],["a63b3b1b53bf96a76fd2d7d5b6b891c064ce7f52","aa00819e304141d872f2e4b1c4be422ea3abbfe1@calxeda.com","ARM: 7492/1: add strstr declaration for decompressors\n\nWith the generic unaligned.h, more kernel headers get pulled in including\ndynamic_debug.h which needs strstr. As it is not really used, we only need\na declaration here.\n\nChange-Id: Icfb000d1e07ae6f112c72ab475f9de0d10918863\nSigned-off-by: Rob Herring <rob.herring@calxeda.com>\nTested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>\nReviewed-by: Arnd Bergmann <arnd@arndb.de>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Rob Herring",true],["4858b2591a4bae696986f63841c75a3b9121d756","b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","ARM: 7592/1: nommu: prevent generation of kernel unaligned memory accesses\n\nRecent ARMv7 toolchains assume that unaligned memory accesses will not\nfault and will instead be handled by the processor.\n\nFor the nommu case (without an MPU), memory will be treated as\nstrongly-ordered and therefore unaligned accesses may fault regardless\nof the SCTLR.A setting.\n\nThis patch passes -mno-unaligned-access to GCC when compiling for nommu\ntargets, preventing the generation of unaligned memory access in the\nkernel.\n\nChange-Id: I647668bd04b79bee521870665be2cfd3278a558a\nAcked-by: Nicolas Pitre <nico@linaro.org>\nTested-by: Jonathan Austin <jonathan.austin@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Will Deacon",true],["162aeb7a78c12700518cd4ca6c598f3eea28ab05","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","ARM: 7593/1: nommu: do not enable DCACHE_WORD_ACCESS when !CONFIG_MMU\n\nCommit b9a50f74905a (\"ARM: 7450/1: dcache: select DCACHE_WORD_ACCESS for\nlittle-endian ARMv6+ CPUs\") added support for word-at-time path\ncomparisons, relying on the ability to perform unaligned loads with\nnegligible performance impact in hardware.\n\nFor nommu configurations without MPU support, this is unpredictable and\nso we should fall back to the byte-by-byte routines.\n\nAcked-by: Nicolas Pitre <nico@linaro.org>\nTested-by: Jonathan Austin <jonathan.austin@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nmodified for Mako from kernel.org\n\nChange-Id: Ib5c7b2ecf4b08f03ae80eb464cc8265f8298c873\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true],["1a8eafe8fe8253f36606deaaa77c9eea33474e1b","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","kernel: Move REPEAT_BYTE definition into linux/kernel.h\n\nAnd make sure that everything using it explicitly includes\nthat header file.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nmodified for Mako kernel from kernel.org\n\nChange-Id: Iee244455a17dfbbdbac472eaa3f3660fdeba49a5\nSigned-off-by: faux123 <reioux@gmail.com>","faux123",true]],"size":37,"ref":"refs/heads/kk4.4","head":"12a0f4d718ef1d65776423f6ad773248bdcee937"}