aboutsummaryrefslogtreecommitdiffstats
path: root/arch/sparc
Commit message (Collapse)AuthorAge
...
| * | | sparc64: Fix bugs in unrolled 256-bit loops.David S. Miller2012-09-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Avoid code duplication in crypto assembler.David S. Miller2012-08-31
| | | | | | | | | | | | | | | | | | | | | | | | Put the opcode macros in a common header Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Unroll CTR crypt loops in AES driver.David S. Miller2012-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Unroll ECB decryption loops in AES driver.David S. Miller2012-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Unroll ECB encryption loops in AES driver.David S. Miller2012-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Add ctr mode support to AES driver.David S. Miller2012-08-29
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Move AES driver over to a methods based implementation.David S. Miller2012-08-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Use fsrc2 instead of fsrc1 in sparc64 hash crypto drivers.David S. Miller2012-08-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Add CAMELLIA driver making use of the new camellia opcodes.David S. Miller2012-08-28
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Fix spelling of CAMELLIA in CFR macro name and comment.David S. Miller2012-08-28
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Add DES driver making use of the new des opcodes.David S. Miller2012-08-26
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Add CRC32C driver making use of the new crc32c opcode.David S. Miller2012-08-22
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Add AES driver making use of the new aes opcodes.David S. Miller2012-08-22
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | | sparc64: Add MD5 driver making use of the 'md5' instruction.David S. Miller2012-08-20
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | | sparc64: Add SHA384/SHA512 driver making use of the 'sha512' instruction.David S. Miller2012-08-20
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | | sparc64: Add SHA224/SHA256 driver making use of the 'sha256' instruction.David S. Miller2012-08-20
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | | sparc64: Add SHA1 driver making use of the 'sha1' instruction.David S. Miller2012-08-20
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
| * | | sparc64: Update generic comments in perf event code to match reality.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Add SPARC-T4 perf event support.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Support perf event encoding for multi-PCR PMUs.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Make sparc_pmu_{enable,disable}_event() multi-pcr aware.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Rework sparc_pmu_enable() so that the side effects are clearer.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Prepare perf event layer for handling multiple PCR registers.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Specify user and supervisor trace PCR bits in sparc_pmu.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Abstract PMC read/write behind sparc_pmu.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Allow max hw perf events to be variable.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | Now specified in sparc_pmu descriptor. Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Add perf_event abstractions for orthogonal PMUs.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Add PCR ops for SPARC-T4.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is enough to get the NMIs working, more work is needed for perf events. Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Abstract away the %pcr values used to enable/disable NMIDavid S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Abstract away the NMI PIC counter computation.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Abstract away PIC register accesses.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Add 'reg_num' argument to pcr_ops methods.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | SPARC-T4 and later have multiple PCR registers, one for each PIC counter. Signed-off-by: David S. Miller <davem@davemloft.net>
| * | | sparc64: Add hypervisor interfaces for SPARC-T4 perf counter access.David S. Miller2012-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | sparc64: Add detection for features new in SPARC-T4.David S. Miller2012-08-19
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge tag 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds2012-10-01
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull PCI changes from Bjorn Helgaas: "Host bridge hotplug - Protect acpi_pci_drivers and acpi_pci_roots (Taku Izumi) - Clear host bridge resource info to avoid issue when releasing (Yinghai Lu) - Notify acpi_pci_drivers when hot-plugging host bridges (Jiang Liu) - Use standard list ops for acpi_pci_drivers (Jiang Liu) Device hotplug - Use pci_get_domain_bus_and_slot() to close hotplug races (Jiang Liu) - Remove fakephp driver (Bjorn Helgaas) - Fix VGA ref count in hotplug remove path (Yinghai Lu) - Allow acpiphp to handle PCIe ports without native hotplug (Jiang Liu) - Implement resume regardless of pciehp_force param (Oliver Neukum) - Make pci_fixup_irqs() work after init (Thierry Reding) Miscellaneous - Add pci_pcie_type(dev) and remove pci_dev.pcie_type (Yijing Wang) - Factor out PCI Express Capability accessors (Jiang Liu) - Add pcibios_window_alignment() so powerpc EEH can use generic resource assignment (Gavin Shan) - Make pci_error_handlers const (Stephen Hemminger) - Cleanup drivers/pci/remove.c (Bjorn Helgaas) - Improve Vendor-Specific Extended Capability support (Bjorn Helgaas) - Use standard list ops for bus->devices (Bjorn Helgaas) - Avoid kmalloc in pci_get_subsys() and pci_get_class() (Feng Tang) - Reassign invalid bus number ranges (Intel DP43BF workaround) (Yinghai Lu)" * tag 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (102 commits) PCI: acpiphp: Handle PCIe ports without native hotplug capability PCI/ACPI: Use acpi_driver_data() rather than searching acpi_pci_roots PCI/ACPI: Protect acpi_pci_roots list with mutex PCI/ACPI: Use acpi_pci_root info rather than looking it up again PCI/ACPI: Pass acpi_pci_root to acpi_pci_drivers' add/remove interface PCI/ACPI: Protect acpi_pci_drivers list with mutex PCI/ACPI: Notify acpi_pci_drivers when hot-plugging PCI root bridges PCI/ACPI: Use normal list for struct acpi_pci_driver PCI/ACPI: Use DEVICE_ACPI_HANDLE rather than searching acpi_pci_roots PCI: Fix default vga ref_count ia64/PCI: Clear host bridge aperture struct resource x86/PCI: Clear host bridge aperture struct resource PCI: Stop all children first, before removing all children Revert "PCI: Use hotplug-safe pci_get_domain_bus_and_slot()" PCI: Provide a default pcibios_update_irq() PCI: Discard __init annotations for pci_fixup_irqs() and related functions PCI: Use correct type when freeing bus resource list PCI: Check P2P bridge for invalid secondary/subordinate range PCI: Convert "new_id"/"remove_id" into generic pci_bus driver attributes xen-pcifront: Use hotplug-safe pci_get_domain_bus_and_slot() ...
| * | PCI: Provide a default pcibios_update_irq()Thierry Reding2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Most architectures implement this in exactly the same way. Instead of having each architecture duplicate this function, provide a single implementation in the core and make it a weak symbol so that it can be overridden on architectures where it is required. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
| * | PCI: Discard __init annotations for pci_fixup_irqs() and related functionsThierry Reding2012-09-18
| |/ | | | | | | | | | | | | | | | | | | | | Remove the __init annotations in order to keep pci_fixup_irqs() around after init (e.g. for hotplug). This requires the same change for the implementation of pcibios_update_irq() on all architectures. While at it, all __devinit annotations are removed as well, since they will be useless now that HOTPLUG is always on. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | sparc: fix the return value of module_alloc()Wei Yongjun2012-09-21
| | | | | | | | | | | | | | | | | | | | | | | | In case of error, function module_alloc() in other platform never returns ERR_PTR(), and all of the user only check for NULL, so we'd better return NULL instead of ERR_PTR(). dpatch engine is used to auto generated this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
* | sparc32: Enable the relocation target R_SPARC_DISP32 for sparc32Andreas Larsson2012-09-21
|/ | | | | | | GNU Binutils 2.20.1 generates .eh_frame sections that uses R_SPARC_DISP32. Signed-off-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Be less verbose during vmemmap population.David S. Miller2012-08-15
| | | | | | | | | | | | | | | | 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>
* sparc64: do not clobber personality flags in sys_sparc64_personality()Jiri Kosina2012-08-02
| | | | | | | | | | | | | | | | | | | There are multiple errors in how sys_sparc64_personality() handles personality flags stored in top three bytes. - directly comparing current->personality against PER_LINUX32 doesn't work in cases when any of the personality flags stored in the top three bytes are used. - directly forcefully setting personality to PER_LINUX32 or PER_LINUX discards any flags stored in the top three bytes Fix the first one by properly using personality() macro to compare only PER_MASK bytes. Fix the second one by setting only the bits that should be set, instead of overwriting the whole value. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'random_for_linus' of ↵Linus Torvalds2012-07-31
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random Pull random subsystem patches from Ted Ts'o: "This patch series contains a major revamp of how we collect entropy from interrupts for /dev/random and /dev/urandom. The goal is to addresses weaknesses discussed in the paper "Mining your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", by Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex Halderman, which will be published in the Proceedings of the 21st Usenix Security Symposium, August 2012. (See https://factorable.net for more information and an extended version of the paper.)" Fix up trivial conflicts due to nearby changes in drivers/{mfd/ab3100-core.c, usb/gadget/omap_udc.c} * tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random: (33 commits) random: mix in architectural randomness in extract_buf() dmi: Feed DMI table to /dev/random driver random: Add comment to random_initialize() random: final removal of IRQF_SAMPLE_RANDOM um: remove IRQF_SAMPLE_RANDOM which is now a no-op sparc/ldc: remove IRQF_SAMPLE_RANDOM which is now a no-op [ARM] pxa: remove IRQF_SAMPLE_RANDOM which is now a no-op board-palmz71: remove IRQF_SAMPLE_RANDOM which is now a no-op isp1301_omap: remove IRQF_SAMPLE_RANDOM which is now a no-op pxa25x_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op omap_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op goku_udc: remove IRQF_SAMPLE_RANDOM which was commented out uartlite: remove IRQF_SAMPLE_RANDOM which is now a no-op drivers: hv: remove IRQF_SAMPLE_RANDOM which is now a no-op xen-blkfront: remove IRQF_SAMPLE_RANDOM which is now a no-op n2_crypto: remove IRQF_SAMPLE_RANDOM which is now a no-op pda_power: remove IRQF_SAMPLE_RANDOM which is now a no-op i2c-pmcmsp: remove IRQF_SAMPLE_RANDOM which is now a no-op input/serio/hp_sdc.c: remove IRQF_SAMPLE_RANDOM which is now a no-op mfd: remove IRQF_SAMPLE_RANDOM which is now a no-op ...
| * sparc/ldc: remove IRQF_SAMPLE_RANDOM which is now a no-opTheodore Ts'o2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | With the changes in the random tree, IRQF_SAMPLE_RANDOM is now a no-op; interrupt randomness is now collected unconditionally in a very low-overhead fashion; see commit 775f4b297b. The IRQF_SAMPLE_RANDOM flag was scheduled to be removed in 2009 on the feature-removal-schedule, so this patch is preparation for the final removal of this flag. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Acked-by: "David S. Miller" <davem@davemloft.net>
* | ipc: use Kconfig options for __ARCH_WANT_[COMPAT_]IPC_PARSE_VERSIONWill Deacon2012-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than #define the options manually in the architecture code, add Kconfig options for them and select them there instead. This also allows us to select the compat IPC version parsing automatically for platforms using the old compat IPC interface. Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | ipc: add COMPAT_SHMLBA supportWill Deacon2012-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the SHMLBA definition for a native task differs from the definition for a compat task, the do_shmat() function would need to handle both. This patch introduces COMPAT_SHMLBA, which is used by the compat shmat syscall when calling the ipc code and allows architectures such as AArch64 (where the native SHMLBA is 64k but the compat (AArch32) definition is 16k) to provide the correct semantics for compat IPC system calls. Cc: David S. Miller <davem@davemloft.net> Cc: Chris Zankel <chris@zankel.net> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds2012-07-26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull sparc updates from David Miller: "Nothing much this merge window for sparc. 1) Fix FPU state management in sparc32, from Tkhai Kirill. 2) More sparc32 mm layer code cleanups, largely more side effects of the sun4c support removal in the 3.5 From Sam Ravnborg. 3) Remove unused code in sparc64, from Bjorn Helgaas and Kirill Tkhai. 4) Some declaration and comment tidies in PROM support code, from Geert Uytterhoeven." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: (24 commits) sparc32, copy_thread: Clear TIF_USEDFPU flag of created task instead of current sparc32: delete dead code in show_mem() sparc32: move kmap_init() to highmem.c sparc32: move probe_memory() to srmmu.c sparc32: drop unused BAD_PAGE stuff sparc32: centralize all mmu context handling in srmmu.c sparc32: drop quicklist sparc32: drop sparc model check in paging_init sparc32: drop sparc_unmapped_base sparc32,leon: drop leon_init() sparc32: drop fixmap.h sparc32: fixmap.h cleanup sparc32: drop unused kmap_atomic_to_page sparc32: drop swapper_pg_dir sparc32: beautify srmmu_inherit_prom_mappings() sparc32: use void * in nocache get/free sparc32: fix coding-style in srmmu.c sparc32: sort includes in srmmu.c sparc32: define a few srmmu functions __init sparc64: remove unused function straddles_64bit_va_hole() ...
| * | sparc32, copy_thread: Clear TIF_USEDFPU flag of created task instead of currentTkhai Kirill2012-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FPU state is saved into task_struct of created task. Current task continues use of the state, so it needs TIF_USEDFPU flag is not cleared. Created task receives fresh FPU and cleared TIF_USEFPU flag is required for it. Signed-off-by: Kirill Tkhai <tkhai@yandex.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sparc32: delete dead code in show_mem()Sam Ravnborg2012-07-26
| | | | | | | | | | | | | | | Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sparc32: move kmap_init() to highmem.cSam Ravnborg2012-07-26
| | | | | | | | | | | | | | | | | | | | | Try to keep highmem support in a more central place. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | sparc32: move probe_memory() to srmmu.cSam Ravnborg2012-07-26
| | | | | | | | | | | | | | | | | | | | | | | | Only one user so move it to the file using it. It had nothing to do in fault_32. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>