summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2012-09-06sparc64: Use cpu_pgsz_mask for linear kernel mapping config.David S. Miller
This required a little bit of reordering of how we set up the memory management early on. We now only know the final values of kern_linear_pte_xor[] after we take over the trap table and start processing TLB misses ourselves. So once we fill those values in we re-clear the kernel's 4M TSB and flush the TLBs. That way if we find we support larger than 4M pages we won't have any stale smaller page size entries in the TSB. SUN4U Panther support for larger page sizes should now be extremely trivial but I have no hardware on which to test it and I believe that some of the sun4u TLB miss assembler needs to be audited first to make sure it really can handle larger than 4M PTEs properly. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-06sparc64: Probe cpu page size support more portably.David S. Miller
On sun4v, interrogate the machine description. This code is extremely defensive in nature, and a lot of the checks can probably be removed. On sun4u things are a lot simpler. There are the page sizes all chips support, and then Panther adds 32MB and 256MB pages. Report the probed value in /proc/cpuinfo Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-06sparc64: Support 2GB and 16GB page sizes for kernel linear mappings.David S. Miller
SPARC-T4 supports 2GB pages. So convert kpte_linear_bitmap into an array of 2-bit values which index into kern_linear_pte_xor. Now kern_linear_pte_xor is used for 4 page size aligned regions, 4MB, 256MB, 2GB, and 16GB respectively. Enabling 2GB pages is currently hardcoded using a check against sun4v_chip_type. In the future this will be done more cleanly by interrogating the machine description which is the correct way to determine this kind of thing. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-01sparc64: Fix bugs in unrolled 256-bit loops.David S. Miller
Some dm-crypt testing revealed several bugs in the 256-bit unrolled loops. The DECRYPT_256_2() macro had two errors: 1) Missing reload of KEY registers %f60 and %f62 2) Missing "\" in penultimate line of definition. In aes_sparc64_ecb_decrypt_256, we were storing the second half of the encryption result from the wrong source registers. In aes_sparc64_ctr_crypt_256 we have to be careful when we fall out of the 32-byte-at-a-time loop and handle a trailing 16-byte chunk. In that case we've clobbered the final key holding registers and have to restore them before executing the ENCRYPT_256() macro. Inside of the 32-byte-at-a-time loop things are OK, because we do this key register restoring during the first few rounds of the ENCRYPT_256_2() macro. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-31sparc64: Avoid code duplication in crypto assembler.David S. Miller
Put the opcode macros in a common header Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-30sparc64: Unroll CTR crypt loops in AES driver.David S. Miller
Before: testing speed of ctr(aes) encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 206 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 244 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 360 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 814 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 5021 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 206 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 240 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 378 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 939 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 6395 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 209 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 249 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 414 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1073 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 7110 cycles (8192 bytes) testing speed of ctr(aes) decryption test 0 (128 bit key, 16 byte blocks): 1 operation in 225 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 233 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 344 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 810 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 5021 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 206 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 240 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 376 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 938 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 6380 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 214 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 251 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 411 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1070 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 7114 cycles (8192 bytes) After: testing speed of ctr(aes) encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 211 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 246 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 344 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 799 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 4975 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 210 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 236 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 365 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 888 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 6055 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 209 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 255 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 404 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1010 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 6669 cycles (8192 bytes) testing speed of ctr(aes) decryption test 0 (128 bit key, 16 byte blocks): 1 operation in 210 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 233 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 340 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 818 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 4956 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 206 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 239 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 361 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 888 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 5996 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 214 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 248 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 395 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 1010 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 6664 cycles (8192 bytes) Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-30sparc64: Unroll ECB decryption loops in AES driver.David S. Miller
Before: testing speed of ecb(aes) decryption test 0 (128 bit key, 16 byte blocks): 1 operation in 223 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 230 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 325 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 719 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 4266 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 211 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 234 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 353 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 808 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 5344 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 214 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 243 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 393 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 939 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 6039 cycles (8192 bytes) After: testing speed of ecb(aes) decryption test 0 (128 bit key, 16 byte blocks): 1 operation in 226 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 231 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 313 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 681 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 3964 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 205 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 240 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 341 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 770 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 5050 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 216 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 250 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 371 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 869 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 5494 cycles (8192 bytes) Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-30sparc64: Unroll ECB encryption loops in AES driver.David S. Miller
The AES opcodes have a 3 cycle latency, so by doing 32-bytes at a time we avoid a pipeline bubble in between every round. For the 256-bit key case, it looks like we're doing more work in order to reload the KEY registers during the loop to make space for scarce temporaries. But the load dual issues with the AES operations so we get the KEY reloads essentially for free. Before: testing speed of ecb(aes) encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 264 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 231 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 329 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 715 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 4248 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 221 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 234 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 359 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 803 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 5366 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 209 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 255 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 379 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 938 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 6041 cycles (8192 bytes) After: testing speed of ecb(aes) encryption test 0 (128 bit key, 16 byte blocks): 1 operation in 266 cycles (16 bytes) test 1 (128 bit key, 64 byte blocks): 1 operation in 256 cycles (64 bytes) test 2 (128 bit key, 256 byte blocks): 1 operation in 305 cycles (256 bytes) test 3 (128 bit key, 1024 byte blocks): 1 operation in 676 cycles (1024 bytes) test 4 (128 bit key, 8192 byte blocks): 1 operation in 3981 cycles (8192 bytes) test 5 (192 bit key, 16 byte blocks): 1 operation in 210 cycles (16 bytes) test 6 (192 bit key, 64 byte blocks): 1 operation in 233 cycles (64 bytes) test 7 (192 bit key, 256 byte blocks): 1 operation in 340 cycles (256 bytes) test 8 (192 bit key, 1024 byte blocks): 1 operation in 766 cycles (1024 bytes) test 9 (192 bit key, 8192 byte blocks): 1 operation in 5136 cycles (8192 bytes) test 10 (256 bit key, 16 byte blocks): 1 operation in 206 cycles (16 bytes) test 11 (256 bit key, 64 byte blocks): 1 operation in 268 cycles (64 bytes) test 12 (256 bit key, 256 byte blocks): 1 operation in 368 cycles (256 bytes) test 13 (256 bit key, 1024 byte blocks): 1 operation in 890 cycles (1024 bytes) test 14 (256 bit key, 8192 byte blocks): 1 operation in 5718 cycles (8192 bytes) Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-29sparc64: Add ctr mode support to AES driver.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-29sparc64: Move AES driver over to a methods based implementation.David S. Miller
Instead of testing and branching off of the key size on every encrypt/decrypt call, use method ops assigned at key set time. Reverse the order of float registers used for decryption to make future changes easier. Align all assembler routines on a 32-byte boundary. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-28sparc64: Use fsrc2 instead of fsrc1 in sparc64 hash crypto drivers.David S. Miller
On SPARC-T4 fsrc2 has 1 cycle of latency, whereas fsrc1 has 11 cycles. True story. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-28sparc64: Add CAMELLIA driver making use of the new camellia opcodes.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-28sparc64: Fix spelling of CAMELLIA in CFR macro name and comment.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-25sparc64: Add DES driver making use of the new des opcodes.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-22sparc64: Add CRC32C driver making use of the new crc32c opcode.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-22sparc64: Add AES driver making use of the new aes opcodes.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20sparc64: Add MD5 driver making use of the 'md5' instruction.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20sparc64: Add SHA384/SHA512 driver making use of the 'sha512' instruction.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20sparc64: Add SHA224/SHA256 driver making use of the 'sha256' instruction.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20sparc64: Add SHA1 driver making use of the 'sha1' instruction.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-18sparc64: Update generic comments in perf event code to match reality.David S. Miller
Describe how we support two types of PMU setups, one with a single control register and two counters stored in a single register, and another with one control register per counter and each counter living in it's own register. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Add SPARC-T4 perf event support.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Support perf event encoding for multi-PCR PMUs.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Make sparc_pmu_{enable,disable}_event() multi-pcr aware.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Rework sparc_pmu_enable() so that the side effects are clearer.David S. Miller
When cpuc->n_events is zero, we actually don't do anything and we just write the cpuc->pcr[0] value as-is without any modifications. The "pcr = 0;" assignment there was just useless and confusing. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Prepare perf event layer for handling multiple PCR registers.David S. Miller
Make the per-cpu pcr save area an array instead of one u64. Describe how many PCR and PIC registers the chip has in the sparc_pmu descriptor. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Specify user and supervisor trace PCR bits in sparc_pmu.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Abstract PMC read/write behind sparc_pmu.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Allow max hw perf events to be variable.David S. Miller
Now specified in sparc_pmu descriptor. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Add perf_event abstractions for orthogonal PMUs.David S. Miller
Starting with SPARC-T4 we have a seperate PCR control register for each performance counter, and there are absolutely no restrictions on what events can run on which counters. Add flags that we can use to elide the conflict and dependency logic used to handle older chips. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Add PCR ops for SPARC-T4.David S. Miller
This is enough to get the NMIs working, more work is needed for perf events. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Abstract away the %pcr values used to enable/disable NMIDavid S. Miller
We assumed PCR_PIC_PRIV can always be used to disable it, but that won't be true for SPARC-T4. This allows us also to get rid of some messy defines used in only one location. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Abstract away the NMI PIC counter computation.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Abstract away PIC register accesses.David S. Miller
And, like for the PCR, allow indexing of different PIC register numbers. This also removes all of the non-__KERNEL__ bits from asm/perfctr.h, nothing kernel side should include it any more. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Add 'reg_num' argument to pcr_ops methods.David S. Miller
SPARC-T4 and later have multiple PCR registers, one for each PIC counter. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Add hypervisor interfaces for SPARC-T4 perf counter access.David S. Miller
Unlike for previous chips, access to the perf-counter control registers are all hyper-privileged. Therefore, access to them must go through a hypervisor interface. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18sparc64: Add detection for features new in SPARC-T4.David S. Miller
Compare and branch, pause, and the various new cryptographic opcodes. We advertise the crypto opcodes to userspace using one hwcap bit, HWCAP_SPARC_CRYPTO. This essentially indicates that the %cfr register can be interrograted and used to determine exactly which crypto opcodes are available on the current cpu. We use the %cfr register to report all of the crypto opcodes available in the bootup CPU caps log message, and via /proc/cpuinfo. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "The largest thing in this set of changes is bringing back some of the ARMv3 code to fix a compile problem noticed on RiscPC, which we still support, even though we only support ARMv4 there. (The reason is that the system bus doesn't support ARMv4 half-word accesses, so we need the ARMv3 library code for this platform.) The rest are all quite minor fixes." * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: 7490/1: Drop duplicate select for GENERIC_IRQ_PROBE ARM: Bring back ARMv3 IO and user access code ARM: 7489/1: errata: fix workaround for erratum #720789 on UP systems ARM: 7488/1: mm: use 5 bits for swapfile type encoding ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present ARM: 7486/1: sched_clock: update epoch_cyc on resume ARM: 7484/1: Don't enable GENERIC_LOCKBREAK with ticket spinlocks ARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled ARM: 7482/1: topology: fix section mismatch warning for init_cpu_topology
2012-08-17Merge tag 'for-linus' of git://linux-c6x.org/git/projects/linux-c6x-upstreamingLinus Torvalds
Pull C6X atomic64 support from Mark Salter: "Enable atomic64 ops in C6X - define L1_CACHE_SHIFT - select GENERIC_ATOMIC64" * tag 'for-linus' of git://linux-c6x.org/git/projects/linux-c6x-upstreaming: C6X: select GENERIC_ATOMIC64 C6X: add Lx_CACHE_SHIFT defines
2012-08-16Merge tag 'stable/for-linus-3.6-rc1-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull Xen fix from Konrad Rzeszutek Wilk: "Way back in v3.5 we added a mechanism to populate back pages that were released (they overlapped with MMIO regions), but neglected to reserve the proper amount of virtual space for extend_brk to work properly. Coincidentally some other commit aligned the _brk space to larger area so I didn't trigger this until it was run on a machine with more than 2GB of MMIO space." * On machines with large MMIO/PCI E820 spaces we fail to boot b/c we failed to pre-allocate large enough virtual space for extend_brk. * tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
2012-08-16Merge tag 'sh-for-linus' of git://github.com/pmundt/linux-shLinus Torvalds
Pull SuperH fixes from Paul Mundt. * tag 'sh-for-linus' of git://github.com/pmundt/linux-sh: sh: intc: Handle domain association for sparseirq pre-allocated vectors. sh: sh7269: Fix LCD pinmux sh: dma: fix request_irq usage
2012-08-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds
Pull two sparc fixes from David S. Miller. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Be less verbose during vmemmap population. sparc64: do not clobber personality flags in sys_sparc64_personality()
2012-08-15C6X: select GENERIC_ATOMIC64Mark Salter
The generic atomic64 support came in 2009 to support the perf subsystem with the expectation that all architectures would implement atomic64 support. Since then, other optional parts of the generic kernel have also come to expect atomic64 support. This patch enables generic atomic64 support for C6X architecture. Signed-off-by: Mark Salter <msalter@redhat.com>
2012-08-15C6X: add Lx_CACHE_SHIFT definesMark Salter
C6X currently lacks Lx_CACHE_SHIFT defines which are needed in a few places in the generic kernel. This patch adds _SHIFT defines for the various caches and bases the Lx_CACHE_BYTES defines on them. Signed-off-by: Mark Salter <msalter@redhat.com>
2012-08-15ARM: 7490/1: Drop duplicate select for GENERIC_IRQ_PROBEStephen Boyd
Seems that Thomas' and my patches collided during the last merge window. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-15sparc64: Be less verbose during vmemmap population.David S. Miller
On a 2-node machine with 256GB of ram we get 512 lines of console output, which is just too much. This mimicks Yinghai Lu's x86 commit c2b91e2eec9678dbda274e906cc32ea8f711da3b (x86_64/mm: check and print vmemmap allocation continuous) except that we aren't ever going to get contiguous block pointers in between calls so just print when the virtual address or node changes. This decreases the output by an order of 16. Also demote this to KERN_DEBUG. Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-14Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 patches from Martin Schwidefsky: "Included are bug fixes and a patch to enable system call filtering with BPF." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/compat: fix mmap compat system calls s390/compat: fix compat wrappers for process_vm system calls s390: do not clobber personality flags in sys_32_personality() s390/seccomp: add support for system call filtering using BPF s390/sclp_sdias: Add missing break and "fall through" s390/mm: remove MAX_PHYSADDR_BITS define
2012-08-13ARM: Bring back ARMv3 IO and user access codeRussell King
This partially reverts 357c9c1f07d4546bc3fbc0fd1044d96b114d14ed (ARM: Remove support for ARMv3 ARM610 and ARM710 CPUs). Although we only support StrongARM on the RiscPC, we need to keep the ARMv3 user access code for this platform because the bus does not understand half-word load/stores. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-12Merge tag 'gpio-fixes-v3.6-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull gpio fixes from Linus Walleij: - Fix a resource leak in the SCH driver - Fix the register address calculation in the MSIC driver - Fix the PXA driver's devicetree functions - Delete redundant shadow variable leftovers in the MXC driver - Specify the GPIO base for the device tree probe in the MXC driver - Add a modalias for the i.MX driver - Fix off-by-one bug in the Samsung driver - Fix erroneous errorpath in the Langwell driver * tag 'gpio-fixes-v3.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: drivers/gpio/gpio-langwell.c: fix error return code gpio: samsung: Fix off-by-one bug in gpio addresses ARM: dts: imx: add alias for gpio gpio/mxc: specify gpio base for device tree probe gpio/mxc: remove redundant shadow variables initialization GPIO: gpio-pxa: fix devicetree functions gpio: msic: Fix calculating register address in msic_gpio_to_oreg() gpio-sch: Fix leak of resource
2012-08-12Merge tag 'fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull arm-soc bug fixes from Arnd Bergmann: "These are a bunch of bug fixes that came in after the merge window and one update for the MAINTAINERS file. The largest part of the fixes are patches that address bugs found by building all the ARM defconfig files. There are a lot more warnings that we have patches for, but the others are either still under discussion or are harmless and do not cause actual problems besides making the build slightly noisy." * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (30 commits) ARM: davinci: remove broken ntosd2_init_i2c ARM: s3c24xx: enable CONFIG_BUG for tct_hammer omap-rng: fix use of SIMPLE_DEV_PM_OPS spi/s3c64xx: improve error handling mtd/omap2: fix dmaengine_slave_config error handling gpio: em: do not discard em_gio_irq_domain_cleanup ARM: exynos: exynos_pm_add_dev_to_genpd may be unused ARM: imx: gpmi-nand depends on mxs-dma ARM: integrator: include <linux/export.h> ARM: s3c24xx: use new PWM driver ARM: sa1100: include linux/io.h in hackkit leds code Input: eeti_ts: pass gpio value instead of IRQ ARM: pxa: remove irq_to_gpio from ezx-pcap driver ARM: tegra: more regulator fixes for Harmony usb/ohci-omap: remove unused variable mfd/asic3: fix asic3_mfd_probe return value ARM: kirkwood: fix typo in Makefile.boot i.MX27: Fix emma-prp and csi clocks. ARM: integrator: use clk_prepare_enable() for timer MAINTAINERS: update entry for Linus Walleij ...
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-31 21:39:44 +0000