Commit Graph

321857 Commits

Author SHA1 Message Date
David S. Miller ae2c6ca641 sparc64: Add SPARC-T4 optimized memcpy.
Before		After
		--------------	--------------
bw_tcp:         1288.53 MB/sec	1637.77 MB/sec
bw_pipe:        1517.18 MB/sec	2107.61 MB/sec
bw_unix:        1838.38 MB/sec	2640.91 MB/sec

make -s -j128
allmodconfig	5min 49sec	5min 31sec

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-27 00:35:11 -07:00
Peter Senna Tschudin da20116166 drivers/sbus/char: removes unnecessary semicolon
removes unnecessary semicolon

Found by Coccinelle: http://coccinelle.lip6.fr/

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-21 12:08:56 -07:00
Peter Senna Tschudin 20b739fef0 arch/sparc/kernel/pci_sun4v.c: removes unnecessary semicolon
removes unnecessary semicolon

Found by Coccinelle: http://coccinelle.lip6.fr/

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-21 12:08:56 -07:00
David S. Miller 274504f5e6 sparc64: Fix function argument comment in camellia_sparc64_key_expand asm.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-21 12:04:51 -07:00
David S. Miller 65d5fcf5c2 sparc64: Fix IV handling bug in des_sparc64_cbc_decrypt
The IV wasn't being propagated properly past the first loop
iteration.

This bug lived only because the crypto layer tests for
cbc(des) do not have any cases that go more than one loop.

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-17 19:57:30 -07:00
David S. Miller 979e93ca24 sparc64: Add auto-loading mechanism to crypto-opcode drivers.
Just simply provide a device table containing an entry for sun4v cpus,
the capability mask checks in the drivers themselves will take care of
the rest.

This makes the bootup logs on pre-T4 cpus slightly more verbose, with
each driver indicating lack of support for the associated opcode(s).

But this isn't too much of a real problem.

I toyed with the idea of using explicit entries with compatability
fields of "SPARC-T4", "SPARC-T5", etc. but all future cpus will have
some subset of these opcodes available and this would just be one more
pointless thing to do as each new cpu is released with a new string.

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-15 09:46:25 -07:00
David S. Miller 71741680a9 sparc64: Add missing pr_fmt define to crypto opcode drivers.
The hashes and crc32c had it, only the AES/DES/CAMELLIA drivers were
missing it.

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-15 09:17:10 -07:00
David S. Miller 1080362425 sparc64: Adjust crypto priorities.
Make the crypto opcode implementations have a higher priority than
those provides by the ring buffer based Niagara crypto device.

Also, several crypto opcode hashes were not setting the priority value
at all.

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-15 09:06:30 -07:00
David S. Miller c69ad0a3f7 sparc64: Use cpu_pgsz_mask for linear kernel mapping config.
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-06 20:35:36 -07:00
David S. Miller ce33fdc52a sparc64: Probe cpu page size support more portably.
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-06 19:01:25 -07:00
David S. Miller 4f93d21d25 sparc64: Support 2GB and 16GB page sizes for kernel linear mappings.
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-06 18:13:58 -07:00
David S. Miller 699871bc94 sparc64: Fix bugs in unrolled 256-bit loops.
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-09-01 23:05:43 -07:00
David S. Miller 7cff82f5f4 sparc64: Avoid code duplication in crypto assembler.
Put the opcode macros in a common header

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-31 12:11:51 -07:00
David S. Miller 4e71bb49f2 sparc64: Unroll CTR crypt loops in AES driver.
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-30 08:40:44 -07:00
David S. Miller 301013159e sparc64: Unroll ECB decryption loops in AES driver.
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-30 08:11:01 -07:00
David S. Miller 03d168ad12 sparc64: Unroll ECB encryption loops in AES driver.
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-30 07:51:32 -07:00
David S. Miller 9fd130ecbe sparc64: Add ctr mode support to AES driver.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-29 14:49:23 -07:00
David S. Miller 0bdcaf7495 sparc64: Move AES driver over to a methods based implementation.
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-29 14:22:23 -07:00
David S. Miller 45dfe237a8 sparc64: Use fsrc2 instead of fsrc1 in sparc64 hash crypto drivers.
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-28 20:55:19 -07:00
David S. Miller 81658ad0d9 sparc64: Add CAMELLIA driver making use of the new camellia opcodes.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-28 20:51:24 -07:00
David S. Miller 3705665069 sparc64: Fix spelling of CAMELLIA in CFR macro name and comment.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-28 12:08:48 -07:00
David S. Miller c5aac2df65 sparc64: Add DES driver making use of the new des opcodes.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-25 22:37:23 -07:00
David S. Miller 442a7c40b1 sparc64: Add CRC32C driver making use of the new crc32c opcode.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-22 20:47:36 -07:00
David S. Miller 9bf4852d3d sparc64: Add AES driver making use of the new aes opcodes.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-22 14:29:33 -07:00
David S. Miller fa4dfedcc2 sparc64: Add MD5 driver making use of the 'md5' instruction.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20 15:08:50 -07:00
David S. Miller 775e0c6998 sparc64: Add SHA384/SHA512 driver making use of the 'sha512' instruction.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20 15:08:50 -07:00
David S. Miller 86c93b24ef sparc64: Add SHA224/SHA256 driver making use of the 'sha256' instruction.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20 15:08:49 -07:00
David S. Miller 4ff28d4ca9 sparc64: Add SHA1 driver making use of the 'sha1' instruction.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-08-20 15:08:49 -07:00
David S. Miller bab96bda44 sparc64: Update generic comments in perf event code to match reality.
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-18 23:26:21 -07:00
David S. Miller 035ea28dde sparc64: Add SPARC-T4 perf event support.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:21 -07:00
David S. Miller 7a37a0b8f8 sparc64: Support perf event encoding for multi-PCR PMUs.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:21 -07:00
David S. Miller b4f061a4b8 sparc64: Make sparc_pmu_{enable,disable}_event() multi-pcr aware.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:20 -07:00
David S. Miller 5ab9684135 sparc64: Rework sparc_pmu_enable() so that the side effects are clearer.
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-18 23:26:20 -07:00
David S. Miller 3f1a209722 sparc64: Prepare perf event layer for handling multiple PCR registers.
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-18 23:26:20 -07:00
David S. Miller 7ac2ed286f sparc64: Specify user and supervisor trace PCR bits in sparc_pmu.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:20 -07:00
David S. Miller 5344303ca8 sparc64: Abstract PMC read/write behind sparc_pmu.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:20 -07:00
David S. Miller 59660495e8 sparc64: Allow max hw perf events to be variable.
Now specified in sparc_pmu descriptor.

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:19 -07:00
David S. Miller b38e99f5bd sparc64: Add perf_event abstractions for orthogonal PMUs.
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-18 23:26:19 -07:00
David S. Miller 6faaeb8ea3 sparc64: Add PCR ops for SPARC-T4.
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-18 23:26:19 -07:00
David S. Miller ce4a925c29 sparc64: Abstract away the %pcr values used to enable/disable NMI
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-18 23:26:19 -07:00
David S. Miller 73a6b0538c sparc64: Abstract away the NMI PIC counter computation.
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:26:18 -07:00
David S. Miller 09d053c797 sparc64: Abstract away PIC register accesses.
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-18 23:26:14 -07:00
David S. Miller 0bab20ba4c sparc64: Add 'reg_num' argument to pcr_ops methods.
SPARC-T4 and later have multiple PCR registers, one for each
PIC counter.

Signed-off-by: David S. Miller <davem@davemloft.net>
2012-08-18 23:04:08 -07:00
David S. Miller 8c79bfa511 sparc64: Add hypervisor interfaces for SPARC-T4 perf counter access.
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-18 23:03:53 -07:00
David S. Miller 6f859c0e96 sparc64: Add detection for features new in SPARC-T4.
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-18 23:02:36 -07:00
Linus Torvalds 6dab7ede93 Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm
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-18 16:20:05 -07:00
Linus Torvalds d9ec0fdc24 Power management fixes for 3.6-rc3
* Fixes for three obscure problems in the runtime PM core code found recently.
 * Two fixes for the new "coupled" cpuidle code from Colin Cross and
   Jon Medhurst.
 * intel_idle driver fix from Konrad Rzeszutek Wilk.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iQIcBAABAgAGBQJQMAOWAAoJEKhOf7ml8uNswp0QAK2pHmZMU8Pg3mY0Qlovvcmn
 KordhSahzwodvdKMpzGqjk/TO3kJ0dk8YGBY1qIzSySmE6S9qsJKQaaoiNR0Se83
 5ZpGVNfJpFBwzrHQkOMkaZzirC5gegKVykM6jlvh3oZqgqGWDawnzOsGCJvYv0lI
 fSAgIc0CDB2dK5V9zFduXp3Cjv2cGEgW/Dd3ggPYns9JZJTAcHuD6cPdSQVml0JG
 vk2VA1IjqRYyn9eSIOerezwh7iVCrAF5miiADXkaTD1fQ9ZyHYfxuqwM1jpijlkz
 PEuICp4FJ4MTPjKYcJgJct0vdc0uD60dvHz9k7PxDIQ35eFiYJYeSU70oNCqULVh
 lhN0VWqUZI1m7U/jH3f/pCc5x4jVhwQvuEE7yIz8d7nclhWqpBElZgyZ8B3yQiR0
 JSChvGtLgYdXYnk6epw4sL6EZpqQW9Xk/JPJpyEy6KAIY45p8q/a972OmGU35ltN
 qAkeBVcAW836NzgnHPJs17R6VzhxFFegd38NbqRvRsVL0Og9+RoT8P9gt2ZPoQ7O
 jBGT/iKn1GzMSTpDGbgj9Nf3tm1zs+pvZ2fc/niBZH/72eyLQVs8zgm0TJVrTA26
 uKeE7l+R3UrsMhBO28kFsX37q3gOYBjtf2K7u2W1q71aNE6YcXdfJfd2aGDZ1LTQ
 1d9MuFjbR6hKQE2Mb7YH
 =fO1w
 -----END PGP SIGNATURE-----

Merge tag 'pm-for-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael J. Wysocki:
  - Fixes for three obscure problems in the runtime PM core code found
   recently.
 - Two fixes for the new "coupled" cpuidle code from Colin Cross and Jon
   Medhurst.
 - intel_idle driver fix from Konrad Rzeszutek Wilk.

* tag 'pm-for-3.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it.
  cpuidle: Prevent null pointer dereference in cpuidle_coupled_cpu_notify
  cpuidle: coupled: fix sleeping while atomic in cpu notifier
  PM / Runtime: Check device PM QoS setting before "no callbacks" check
  PM / Runtime: Clear power.deferred_resume on success in rpm_suspend()
  PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set
2012-08-18 14:39:19 -07:00
Linus Torvalds 20fb1936de Merge branch 'vfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
Pull vfs fixes from Miklos Szeredi.

This mainly fixes some confusion about whether the open 'mode' variable
passed around should contain the full file type (S_IFREG etc)
information or just the permission mode.  In particular, the lack of
proper file type information had confused fuse.

* 'vfs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
  vfs: fix propagation of atomic_open create error on negative dentry
  fuse: check create mode in atomic open
  vfs: pass right create mode to may_o_create()
  vfs: atomic_open(): fix create mode usage
  vfs: canonicalize create mode in build_open_flags()
2012-08-18 10:02:17 -07:00
Linus Torvalds 1ce41cd849 2 fixes for md, tagged for -stable
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.18 (GNU/Linux)
 
 iQIVAwUAUC7bODnsnt1WYoG5AQLqThAAqMO0TCi84QE5MZbqpWgAwtRjF5wk5D6f
 +Bqu8ifgkCe04zumF+LdsgrYEQmM9cLwLsVwvmFmo2oEtiGWrC4r1dgUMk7qrf5a
 o5/XZeo8Cd/ysEOaD5bjPSIliOTxPq7RlTwAqKuwgZb+l7q5+THxyK5h9y4vFnV9
 l3T4iOJ6y7HmOLM9lS+Dvh8tW1qFjE41cmSVp7mV1YYAKHNfTIE+FIGVFqIXnBh2
 EgA/vOgaYUVkb+688uTAjo3jpCP9aShp7cXceVHW3pIhi7nCXlBYVp5xZxEeLm7B
 LeYNEBl03IsGpPFnglcVP26RybpqK7F+iAZemNBRI19FX0CZoq+qgnTAbIdJDlKI
 GQgkzbgS42pUBqE/MIGK571PGbFjumciaNUtHzVqRg+GA/QOQP5YoWdf4A5kwJ6F
 yD65QlKFR7RTdJC7ZdBRBcrGzUFQWpeW4cBjRyLhMH+hYBdKhJAUW7aLdrisOiJx
 POl8FiECwFswEj9+0s2MIgXM5LjEBG50gjBmgY4YiaqmZ4AVcluDPeF9BERJCWVn
 x0HFAxmTxAMb0FAXBTbg1jH/8f48UzrsSNZ/iRtwjzrDmI3Qr0YMa/abh8ku7HPs
 YXqZJVTXgJ/Kn4VP+UiUOWmbNdkIinkD98/r1Zz3D6Q0zmrKUpiKyk/iCch0Prt4
 8kB6EU2MbIE=
 =MGmm
 -----END PGP SIGNATURE-----

Merge tag 'md-3.6-fixes' of git://neil.brown.name/md

Pull md fixes from NeilBrown:
 "2 fixes for md, tagged for -stable"

* tag 'md-3.6-fixes' of git://neil.brown.name/md:
  md/raid10: fix problem with on-stack allocation of r10bio structure.
  md: Don't truncate size at 4TB for RAID0 and Linear
2012-08-17 17:47:32 -07:00
NeilBrown e0ee778528 md/raid10: fix problem with on-stack allocation of r10bio structure.
A 'struct r10bio' has an array of per-copy information at the end.
This array is declared with size [0] and r10bio_pool_alloc allocates
enough extra space to store the per-copy information depending on the
number of copies needed.

So declaring a 'struct r10bio on the stack isn't going to work.  It
won't allocate enough space, and memory corruption will ensue.

So in the two places where this is done, declare a sufficiently large
structure and use that instead.

The two call-sites of this bug were introduced in 3.4 and 3.5
so this is suitable for both those kernels.  The patch will have to
be modified for 3.4 as it only has one bug.

Cc: stable@vger.kernel.org
Reported-by: Ivan Vasilyev <ivan.vasilyev@gmail.com>
Tested-by: Ivan Vasilyev <ivan.vasilyev@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2012-08-18 09:51:42 +10:00