<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/crypto/caam, branch v3.6</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>crypto/caam: Export gen_split_key symbol for other modules</title>
<updated>2012-09-06T20:07:35+00:00</updated>
<author>
<name>Ben Collins</name>
<email>ben.c@servergy.com</email>
</author>
<published>2012-08-23T22:39:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3b75a2c126c4b573553856e0fe08d1bb020ca8c3'/>
<id>3b75a2c126c4b573553856e0fe08d1bb020ca8c3</id>
<content type='text'>
In 3.6-rc3, without this patch, the following error occurs with a modular build:

ERROR: "gen_split_key" [drivers/crypto/caam/caamhash.ko] undefined!
ERROR: "gen_split_key" [drivers/crypto/caam/caamalg.ko] undefined!

Signed-off-by: Ben Collins &lt;ben.c@servergy.com&gt;
Cc: Yuan Kang &lt;Yuan.Kang@freescale.com&gt;
Acked-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In 3.6-rc3, without this patch, the following error occurs with a modular build:

ERROR: "gen_split_key" [drivers/crypto/caam/caamhash.ko] undefined!
ERROR: "gen_split_key" [drivers/crypto/caam/caamalg.ko] undefined!

Signed-off-by: Ben Collins &lt;ben.c@servergy.com&gt;
Cc: Yuan Kang &lt;Yuan.Kang@freescale.com&gt;
Acked-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - fix possible deadlock condition</title>
<updated>2012-08-20T08:35:40+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-07-13T23:04:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ce026cb9cbf1d529652394ea91fb8a459072be91'/>
<id>ce026cb9cbf1d529652394ea91fb8a459072be91</id>
<content type='text'>
commit "crypto: caam - use non-irq versions of spinlocks for job rings"
made two bad assumptions:

(a) The caam_jr_enqueue lock isn't used in softirq context.
Not true: jr_enqueue can be interrupted by an incoming net
interrupt and the received packet may be sent for encryption,
via caam_jr_enqueue in softirq context, thereby inducing a
deadlock.

This is evidenced when running netperf over an IPSec tunnel
between two P4080's, with spinlock debugging turned on:

[  892.092569] BUG: spinlock lockup on CPU#7, netperf/10634, e8bf5f70
[  892.098747] Call Trace:
[  892.101197] [eff9fc10] [c00084c0] show_stack+0x48/0x15c (unreliable)
[  892.107563] [eff9fc50] [c0239c2c] do_raw_spin_lock+0x16c/0x174
[  892.113399] [eff9fc80] [c0596494] _raw_spin_lock+0x3c/0x50
[  892.118889] [eff9fc90] [c0445e74] caam_jr_enqueue+0xf8/0x250
[  892.124550] [eff9fcd0] [c044a644] aead_decrypt+0x6c/0xc8
[  892.129625] BUG: spinlock lockup on CPU#5, swapper/5/0, e8bf5f70
[  892.129629] Call Trace:
[  892.129637] [effa7c10] [c00084c0] show_stack+0x48/0x15c (unreliable)
[  892.129645] [effa7c50] [c0239c2c] do_raw_spin_lock+0x16c/0x174
[  892.129652] [effa7c80] [c0596494] _raw_spin_lock+0x3c/0x50
[  892.129660] [effa7c90] [c0445e74] caam_jr_enqueue+0xf8/0x250
[  892.129666] [effa7cd0] [c044a644] aead_decrypt+0x6c/0xc8
[  892.129674] [effa7d00] [c0509724] esp_input+0x178/0x334
[  892.129681] [effa7d50] [c0519778] xfrm_input+0x77c/0x818
[  892.129688] [effa7da0] [c050e344] xfrm4_rcv_encap+0x20/0x30
[  892.129697] [effa7db0] [c04b90c8] ip_local_deliver+0x190/0x408
[  892.129703] [effa7de0] [c04b966c] ip_rcv+0x32c/0x898
[  892.129709] [effa7e10] [c048b998] __netif_receive_skb+0x27c/0x4e8
[  892.129715] [effa7e80] [c048d744] netif_receive_skb+0x4c/0x13c
[  892.129726] [effa7eb0] [c03c28ac] _dpa_rx+0x1a8/0x354
[  892.129732] [effa7ef0] [c03c2ac4] ingress_rx_default_dqrr+0x6c/0x108
[  892.129742] [effa7f10] [c0467ae0] qman_poll_dqrr+0x170/0x1d4
[  892.129748] [effa7f40] [c03c153c] dpaa_eth_poll+0x20/0x94
[  892.129754] [effa7f60] [c048dbd0] net_rx_action+0x13c/0x1f4
[  892.129763] [effa7fa0] [c003d1b8] __do_softirq+0x108/0x1b0
[  892.129769] [effa7ff0] [c000df58] call_do_softirq+0x14/0x24
[  892.129775] [ebacfe70] [c0004868] do_softirq+0xd8/0x104
[  892.129780] [ebacfe90] [c003d5a4] irq_exit+0xb8/0xd8
[  892.129786] [ebacfea0] [c0004498] do_IRQ+0xa4/0x1b0
[  892.129792] [ebacfed0] [c000fad8] ret_from_except+0x0/0x18
[  892.129798] [ebacff90] [c0009010] cpu_idle+0x94/0xf0
[  892.129804] [ebacffb0] [c059ff88] start_secondary+0x42c/0x430
[  892.129809] [ebacfff0] [c0001e28] __secondary_start+0x30/0x84
[  892.281474]
[  892.282959] [eff9fd00] [c0509724] esp_input+0x178/0x334
[  892.288186] [eff9fd50] [c0519778] xfrm_input+0x77c/0x818
[  892.293499] [eff9fda0] [c050e344] xfrm4_rcv_encap+0x20/0x30
[  892.299074] [eff9fdb0] [c04b90c8] ip_local_deliver+0x190/0x408
[  892.304907] [eff9fde0] [c04b966c] ip_rcv+0x32c/0x898
[  892.309872] [eff9fe10] [c048b998] __netif_receive_skb+0x27c/0x4e8
[  892.315966] [eff9fe80] [c048d744] netif_receive_skb+0x4c/0x13c
[  892.321803] [eff9feb0] [c03c28ac] _dpa_rx+0x1a8/0x354
[  892.326855] [eff9fef0] [c03c2ac4] ingress_rx_default_dqrr+0x6c/0x108
[  892.333212] [eff9ff10] [c0467ae0] qman_poll_dqrr+0x170/0x1d4
[  892.338872] [eff9ff40] [c03c153c] dpaa_eth_poll+0x20/0x94
[  892.344271] [eff9ff60] [c048dbd0] net_rx_action+0x13c/0x1f4
[  892.349846] [eff9ffa0] [c003d1b8] __do_softirq+0x108/0x1b0
[  892.355338] [eff9fff0] [c000df58] call_do_softirq+0x14/0x24
[  892.360910] [e7169950] [c0004868] do_softirq+0xd8/0x104
[  892.366135] [e7169970] [c003d5a4] irq_exit+0xb8/0xd8
[  892.371101] [e7169980] [c0004498] do_IRQ+0xa4/0x1b0
[  892.375979] [e71699b0] [c000fad8] ret_from_except+0x0/0x18
[  892.381466] [e7169a70] [c0445e74] caam_jr_enqueue+0xf8/0x250
[  892.387127] [e7169ab0] [c044ad4c] aead_givencrypt+0x6ac/0xa70
[  892.392873] [e7169b20] [c050a0b8] esp_output+0x2b4/0x570
[  892.398186] [e7169b80] [c0519b9c] xfrm_output_resume+0x248/0x7c0
[  892.404194] [e7169bb0] [c050e89c] xfrm4_output_finish+0x18/0x28
[  892.410113] [e7169bc0] [c050e8f4] xfrm4_output+0x48/0x98
[  892.415427] [e7169bd0] [c04beac0] ip_local_out+0x48/0x98
[  892.420740] [e7169be0] [c04bec7c] ip_queue_xmit+0x16c/0x490
[  892.426314] [e7169c10] [c04d6128] tcp_transmit_skb+0x35c/0x9a4
[  892.432147] [e7169c70] [c04d6f98] tcp_write_xmit+0x200/0xa04
[  892.437808] [e7169cc0] [c04c8ccc] tcp_sendmsg+0x994/0xcec
[  892.443213] [e7169d40] [c04eebfc] inet_sendmsg+0xd0/0x164
[  892.448617] [e7169d70] [c04792f8] sock_sendmsg+0x8c/0xbc
[  892.453931] [e7169e40] [c047aecc] sys_sendto+0xc0/0xfc
[  892.459069] [e7169f10] [c047b934] sys_socketcall+0x110/0x25c
[  892.464729] [e7169f40] [c000f480] ret_from_syscall+0x0/0x3c

(b) since the caam_jr_dequeue lock is only used in bh context,
then semantically it should use _bh spin_lock types.  spin_lock_bh
semantics are to disable back-halves, and used when a lock is shared
between softirq (bh) context and process and/or h/w IRQ context.
Since the lock is only used within softirq context, and this tasklet
is atomic, there is no need to do the additional work to disable
back halves.

This patch adds back-half disabling protection to caam_jr_enqueue
spin_locks to fix (a), and drops it from caam_jr_dequeue to fix (b).

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit "crypto: caam - use non-irq versions of spinlocks for job rings"
made two bad assumptions:

(a) The caam_jr_enqueue lock isn't used in softirq context.
Not true: jr_enqueue can be interrupted by an incoming net
interrupt and the received packet may be sent for encryption,
via caam_jr_enqueue in softirq context, thereby inducing a
deadlock.

This is evidenced when running netperf over an IPSec tunnel
between two P4080's, with spinlock debugging turned on:

[  892.092569] BUG: spinlock lockup on CPU#7, netperf/10634, e8bf5f70
[  892.098747] Call Trace:
[  892.101197] [eff9fc10] [c00084c0] show_stack+0x48/0x15c (unreliable)
[  892.107563] [eff9fc50] [c0239c2c] do_raw_spin_lock+0x16c/0x174
[  892.113399] [eff9fc80] [c0596494] _raw_spin_lock+0x3c/0x50
[  892.118889] [eff9fc90] [c0445e74] caam_jr_enqueue+0xf8/0x250
[  892.124550] [eff9fcd0] [c044a644] aead_decrypt+0x6c/0xc8
[  892.129625] BUG: spinlock lockup on CPU#5, swapper/5/0, e8bf5f70
[  892.129629] Call Trace:
[  892.129637] [effa7c10] [c00084c0] show_stack+0x48/0x15c (unreliable)
[  892.129645] [effa7c50] [c0239c2c] do_raw_spin_lock+0x16c/0x174
[  892.129652] [effa7c80] [c0596494] _raw_spin_lock+0x3c/0x50
[  892.129660] [effa7c90] [c0445e74] caam_jr_enqueue+0xf8/0x250
[  892.129666] [effa7cd0] [c044a644] aead_decrypt+0x6c/0xc8
[  892.129674] [effa7d00] [c0509724] esp_input+0x178/0x334
[  892.129681] [effa7d50] [c0519778] xfrm_input+0x77c/0x818
[  892.129688] [effa7da0] [c050e344] xfrm4_rcv_encap+0x20/0x30
[  892.129697] [effa7db0] [c04b90c8] ip_local_deliver+0x190/0x408
[  892.129703] [effa7de0] [c04b966c] ip_rcv+0x32c/0x898
[  892.129709] [effa7e10] [c048b998] __netif_receive_skb+0x27c/0x4e8
[  892.129715] [effa7e80] [c048d744] netif_receive_skb+0x4c/0x13c
[  892.129726] [effa7eb0] [c03c28ac] _dpa_rx+0x1a8/0x354
[  892.129732] [effa7ef0] [c03c2ac4] ingress_rx_default_dqrr+0x6c/0x108
[  892.129742] [effa7f10] [c0467ae0] qman_poll_dqrr+0x170/0x1d4
[  892.129748] [effa7f40] [c03c153c] dpaa_eth_poll+0x20/0x94
[  892.129754] [effa7f60] [c048dbd0] net_rx_action+0x13c/0x1f4
[  892.129763] [effa7fa0] [c003d1b8] __do_softirq+0x108/0x1b0
[  892.129769] [effa7ff0] [c000df58] call_do_softirq+0x14/0x24
[  892.129775] [ebacfe70] [c0004868] do_softirq+0xd8/0x104
[  892.129780] [ebacfe90] [c003d5a4] irq_exit+0xb8/0xd8
[  892.129786] [ebacfea0] [c0004498] do_IRQ+0xa4/0x1b0
[  892.129792] [ebacfed0] [c000fad8] ret_from_except+0x0/0x18
[  892.129798] [ebacff90] [c0009010] cpu_idle+0x94/0xf0
[  892.129804] [ebacffb0] [c059ff88] start_secondary+0x42c/0x430
[  892.129809] [ebacfff0] [c0001e28] __secondary_start+0x30/0x84
[  892.281474]
[  892.282959] [eff9fd00] [c0509724] esp_input+0x178/0x334
[  892.288186] [eff9fd50] [c0519778] xfrm_input+0x77c/0x818
[  892.293499] [eff9fda0] [c050e344] xfrm4_rcv_encap+0x20/0x30
[  892.299074] [eff9fdb0] [c04b90c8] ip_local_deliver+0x190/0x408
[  892.304907] [eff9fde0] [c04b966c] ip_rcv+0x32c/0x898
[  892.309872] [eff9fe10] [c048b998] __netif_receive_skb+0x27c/0x4e8
[  892.315966] [eff9fe80] [c048d744] netif_receive_skb+0x4c/0x13c
[  892.321803] [eff9feb0] [c03c28ac] _dpa_rx+0x1a8/0x354
[  892.326855] [eff9fef0] [c03c2ac4] ingress_rx_default_dqrr+0x6c/0x108
[  892.333212] [eff9ff10] [c0467ae0] qman_poll_dqrr+0x170/0x1d4
[  892.338872] [eff9ff40] [c03c153c] dpaa_eth_poll+0x20/0x94
[  892.344271] [eff9ff60] [c048dbd0] net_rx_action+0x13c/0x1f4
[  892.349846] [eff9ffa0] [c003d1b8] __do_softirq+0x108/0x1b0
[  892.355338] [eff9fff0] [c000df58] call_do_softirq+0x14/0x24
[  892.360910] [e7169950] [c0004868] do_softirq+0xd8/0x104
[  892.366135] [e7169970] [c003d5a4] irq_exit+0xb8/0xd8
[  892.371101] [e7169980] [c0004498] do_IRQ+0xa4/0x1b0
[  892.375979] [e71699b0] [c000fad8] ret_from_except+0x0/0x18
[  892.381466] [e7169a70] [c0445e74] caam_jr_enqueue+0xf8/0x250
[  892.387127] [e7169ab0] [c044ad4c] aead_givencrypt+0x6ac/0xa70
[  892.392873] [e7169b20] [c050a0b8] esp_output+0x2b4/0x570
[  892.398186] [e7169b80] [c0519b9c] xfrm_output_resume+0x248/0x7c0
[  892.404194] [e7169bb0] [c050e89c] xfrm4_output_finish+0x18/0x28
[  892.410113] [e7169bc0] [c050e8f4] xfrm4_output+0x48/0x98
[  892.415427] [e7169bd0] [c04beac0] ip_local_out+0x48/0x98
[  892.420740] [e7169be0] [c04bec7c] ip_queue_xmit+0x16c/0x490
[  892.426314] [e7169c10] [c04d6128] tcp_transmit_skb+0x35c/0x9a4
[  892.432147] [e7169c70] [c04d6f98] tcp_write_xmit+0x200/0xa04
[  892.437808] [e7169cc0] [c04c8ccc] tcp_sendmsg+0x994/0xcec
[  892.443213] [e7169d40] [c04eebfc] inet_sendmsg+0xd0/0x164
[  892.448617] [e7169d70] [c04792f8] sock_sendmsg+0x8c/0xbc
[  892.453931] [e7169e40] [c047aecc] sys_sendto+0xc0/0xfc
[  892.459069] [e7169f10] [c047b934] sys_socketcall+0x110/0x25c
[  892.464729] [e7169f40] [c000f480] ret_from_syscall+0x0/0x3c

(b) since the caam_jr_dequeue lock is only used in bh context,
then semantically it should use _bh spin_lock types.  spin_lock_bh
semantics are to disable back-halves, and used when a lock is shared
between softirq (bh) context and process and/or h/w IRQ context.
Since the lock is only used within softirq context, and this tasklet
is atomic, there is no need to do the additional work to disable
back halves.

This patch adds back-half disabling protection to caam_jr_enqueue
spin_locks to fix (a), and drops it from caam_jr_dequeue to fix (b).

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - ERA retrieval and printing for SEC device</title>
<updated>2012-07-11T03:06:11+00:00</updated>
<author>
<name>Alex Porosanu</name>
<email>alexandru.porosanu@freescale.com</email>
</author>
<published>2012-07-11T03:06:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=82c2f9607b8a4667e9d89613478748f4e2b7288b'/>
<id>82c2f9607b8a4667e9d89613478748f4e2b7288b</id>
<content type='text'>
This patch adds support for retrieving and printing of
SEC ERA information. It is useful for knowing beforehand
what features exist from the SEC point of view on a
certain SoC. Only era-s 1 to 4 are currently supported;
other eras will appear as unknown.

Signed-off-by: Alex Porosanu &lt;alexandru.porosanu@freescale.com&gt;

- rebased onto current cryptodev master
- made caam_eras static

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for retrieving and printing of
SEC ERA information. It is useful for knowing beforehand
what features exist from the SEC point of view on a
certain SoC. Only era-s 1 to 4 are currently supported;
other eras will appear as unknown.

Signed-off-by: Alex Porosanu &lt;alexandru.porosanu@freescale.com&gt;

- rebased onto current cryptodev master
- made caam_eras static

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - Using alloc_coherent for caam job rings</title>
<updated>2012-07-11T03:06:10+00:00</updated>
<author>
<name>Bharat Bhushan</name>
<email>Bharat.Bhushan@freescale.com</email>
</author>
<published>2012-07-11T03:06:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1af8ea862c9a9a6d5dc100850036cc7a641bb242'/>
<id>1af8ea862c9a9a6d5dc100850036cc7a641bb242</id>
<content type='text'>
The caam job rings (input/output job ring) are allocated using
dma_map_single(). These job rings can be visualized as the ring
buffers in which the jobs are en-queued/de-queued. The s/w enqueues
the jobs in input job ring which h/w dequeues and after processing
it copies the jobs in output job ring. Software then de-queues the
job from output ring. Using dma_map/unmap_single() is not preferred
way to allocate memory for this type of requirements because this
adds un-necessary complexity.

Example, if bounce buffer (SWIOTLB) will get used then to make any
change visible in this memory to other processing unit requires
dmap_unmap_single() or dma_sync_single_for_cpu/device(). The
dma_unmap_single() can not be used as this will free the bounce
buffer, this will require changing the job rings on running system
and I seriously doubt that it will be not possible or very complex
to implement. Also using dma_sync_single_for_cpu/device() will also
add unnecessary complexity.

The simple and preferred way is using dma_alloc_coherent() for these
type of memory requirements.

This resolves the Linux boot crash issue when "swiotlb=force" is set
in bootargs on systems which have memory more than 4G.

Signed-off-by: Bharat Bhushan &lt;bharat.bhushan@freescale.com&gt;
Acked-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The caam job rings (input/output job ring) are allocated using
dma_map_single(). These job rings can be visualized as the ring
buffers in which the jobs are en-queued/de-queued. The s/w enqueues
the jobs in input job ring which h/w dequeues and after processing
it copies the jobs in output job ring. Software then de-queues the
job from output ring. Using dma_map/unmap_single() is not preferred
way to allocate memory for this type of requirements because this
adds un-necessary complexity.

Example, if bounce buffer (SWIOTLB) will get used then to make any
change visible in this memory to other processing unit requires
dmap_unmap_single() or dma_sync_single_for_cpu/device(). The
dma_unmap_single() can not be used as this will free the bounce
buffer, this will require changing the job rings on running system
and I seriously doubt that it will be not possible or very complex
to implement. Also using dma_sync_single_for_cpu/device() will also
add unnecessary complexity.

The simple and preferred way is using dma_alloc_coherent() for these
type of memory requirements.

This resolves the Linux boot crash issue when "swiotlb=force" is set
in bootargs on systems which have memory more than 4G.

Signed-off-by: Bharat Bhushan &lt;bharat.bhushan@freescale.com&gt;
Acked-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - one tasklet per job ring</title>
<updated>2012-06-27T06:42:07+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-06-23T00:48:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a0ca6ca022ac197e159bb5d22a08e3c3aebb242c'/>
<id>a0ca6ca022ac197e159bb5d22a08e3c3aebb242c</id>
<content type='text'>
there is no noticeable benefit for multiple cores to process one
job ring's output ring: in fact, we can benefit from cache effects
of having the back-half stay on the core that receives a particular
ring's interrupts, and further relax general contention and the
locking involved with reading outring_used, since tasklets run
atomically.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
there is no noticeable benefit for multiple cores to process one
job ring's output ring: in fact, we can benefit from cache effects
of having the back-half stay on the core that receives a particular
ring's interrupts, and further relax general contention and the
locking involved with reading outring_used, since tasklets run
atomically.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - consolidate memory barriers from job ring en/dequeue</title>
<updated>2012-06-27T06:42:07+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-06-23T00:48:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=14a8e29cc2012394d3e886b11402eabd49a4d609'/>
<id>14a8e29cc2012394d3e886b11402eabd49a4d609</id>
<content type='text'>
Memory barriers are implied by the i/o register write implementation
(at least on Power).  So we can remove the redundant wmb() in
caam_jr_enqueue, and, in dequeue(), hoist the h/w done notification
write up to before we need to increment the head of the ring, and
save an smp_mb.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Memory barriers are implied by the i/o register write implementation
(at least on Power).  So we can remove the redundant wmb() in
caam_jr_enqueue, and, in dequeue(), hoist the h/w done notification
write up to before we need to increment the head of the ring, and
save an smp_mb.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - only query h/w in job ring dequeue path</title>
<updated>2012-06-27T06:42:07+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-06-23T00:48:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a8ea07c21d40cf17dd9cbe3cbf87d477b26c354f'/>
<id>a8ea07c21d40cf17dd9cbe3cbf87d477b26c354f</id>
<content type='text'>
Code was needlessly checking the s/w job ring when there
would be nothing to process if the h/w's output completion
ring were empty anyway.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Code was needlessly checking the s/w job ring when there
would be nothing to process if the h/w's output completion
ring were empty anyway.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - use non-irq versions of spinlocks for job rings</title>
<updated>2012-06-27T06:42:06+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-06-23T00:48:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4bba1e9f41d68279ff2c17db53fbd379692b10bc'/>
<id>4bba1e9f41d68279ff2c17db53fbd379692b10bc</id>
<content type='text'>
The enqueue lock isn't used in any interrupt context, and
the dequeue lock isn't used in the h/w interrupt context,
only in bh context.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The enqueue lock isn't used in any interrupt context, and
the dequeue lock isn't used in the h/w interrupt context,
only in bh context.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - disable IRQ coalescing by default</title>
<updated>2012-06-27T06:42:06+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-06-23T00:48:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1a076689cda8a1d623dcda170b2dc2b476cc6f1a'/>
<id>1a076689cda8a1d623dcda170b2dc2b476cc6f1a</id>
<content type='text'>
It has been observed that in zero-loss benchmarks, when a
slow traffic rate is being tested, the IRQ timer coalescing
parameter was set too high, and the ethernet controller
would start dropping packets because the job ring back half
wouldn't be executed in time before the ethernet controller
would fill its buffers, thereby significantly reducing the
zero-loss performance figures.

Empirical testing has shown that the best zero-loss performance
is achieved when IRQ coalescing is set to minimum values and/or
turned off, since apparently the job ring driver already implements
an adequately-performing general-purpose IRQ mitigation strategy
in software.

Whilst we could go with minimal count (2-8) and timing settings
(192-256), we prefer just turning h/w coalescing altogether off
to minimize setkey latency (due to split key generation), and
for consistent cross-SoC performance (the SEC vs. core clock
ratio changes).

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It has been observed that in zero-loss benchmarks, when a
slow traffic rate is being tested, the IRQ timer coalescing
parameter was set too high, and the ethernet controller
would start dropping packets because the job ring back half
wouldn't be executed in time before the ethernet controller
would fill its buffers, thereby significantly reducing the
zero-loss performance figures.

Empirical testing has shown that the best zero-loss performance
is achieved when IRQ coalescing is set to minimum values and/or
turned off, since apparently the job ring driver already implements
an adequately-performing general-purpose IRQ mitigation strategy
in software.

Whilst we could go with minimal count (2-8) and timing settings
(192-256), we prefer just turning h/w coalescing altogether off
to minimize setkey latency (due to split key generation), and
for consistent cross-SoC performance (the SEC vs. core clock
ratio changes).

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: caam - add support for SEC v5.x RNG4</title>
<updated>2012-06-27T06:42:06+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2012-06-23T00:48:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=281922a1d4f59bdebbe78c1d9f4c50a967eb6cff'/>
<id>281922a1d4f59bdebbe78c1d9f4c50a967eb6cff</id>
<content type='text'>
The SEC v4.x' RNGB h/w block self-initialized.  RNG4, available
on SEC versions 5 and beyond, is based on a different standard
that requires manual initialization.

Also update any new errors From the SEC v5.2 reference manual:
The SEC v5.2's RNG4 unit reuses some error IDs, thus the addition
of rng_err_id_list over the CHA-independent err_id_list.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The SEC v4.x' RNGB h/w block self-initialized.  RNG4, available
on SEC versions 5 and beyond, is based on a different standard
that requires manual initialization.

Also update any new errors From the SEC v5.2 reference manual:
The SEC v5.2's RNG4 unit reuses some error IDs, thus the addition
of rng_err_id_list over the CHA-independent err_id_list.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
</feed>
