<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/crypto/ccp, branch linux-4.9.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>crypto: ccp - ccp_dmaengine_unregister release dma channels</title>
<updated>2022-04-20T07:06:31+00:00</updated>
<author>
<name>Dāvis Mosāns</name>
<email>davispuh@gmail.com</email>
</author>
<published>2022-02-28T03:15:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a6cfd7bbe249906b047b03f1f3885c581908fc72'/>
<id>a6cfd7bbe249906b047b03f1f3885c581908fc72</id>
<content type='text'>
[ Upstream commit 54cce8ecb9254f971b40a72911c6da403720a2d2 ]

ccp_dmaengine_register adds dma_chan-&gt;device_node to dma_dev-&gt;channels list
but ccp_dmaengine_unregister didn't remove them.
That can cause crashes in various dmaengine methods that tries to use dma_dev-&gt;channels

Fixes: 58ea8abf4904 ("crypto: ccp - Register the CCP as a DMA...")
Signed-off-by: Dāvis Mosāns &lt;davispuh@gmail.com&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 54cce8ecb9254f971b40a72911c6da403720a2d2 ]

ccp_dmaengine_register adds dma_chan-&gt;device_node to dma_dev-&gt;channels list
but ccp_dmaengine_unregister didn't remove them.
That can cause crashes in various dmaengine methods that tries to use dma_dev-&gt;channels

Fixes: 58ea8abf4904 ("crypto: ccp - Register the CCP as a DMA...")
Signed-off-by: Dāvis Mosāns &lt;davispuh@gmail.com&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - fix error handling</title>
<updated>2020-10-29T08:05:41+00:00</updated>
<author>
<name>Pavel Machek</name>
<email>pavel@denx.de</email>
</author>
<published>2020-09-21T11:34:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=60f4aa0b9f820e69936c8295e2e28ed9f142fbba'/>
<id>60f4aa0b9f820e69936c8295e2e28ed9f142fbba</id>
<content type='text'>
[ Upstream commit e356c49c6cf0db3f00e1558749170bd56e47652d ]

Fix resource leak in error handling.

Signed-off-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e356c49c6cf0db3f00e1558749170bd56e47652d ]

Fix resource leak in error handling.

Signed-off-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Acked-by: John Allen &lt;john.allen@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Fix use of merged scatterlists</title>
<updated>2020-08-21T09:02:05+00:00</updated>
<author>
<name>John Allen</name>
<email>john.allen@amd.com</email>
</author>
<published>2020-06-22T20:24:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=476c4a59e9f13fa1c5294eaabcc7912531ea2e6f'/>
<id>476c4a59e9f13fa1c5294eaabcc7912531ea2e6f</id>
<content type='text'>
commit 8a302808c60d441d9884cb00ea7f2b534f2e3ca5 upstream.

Running the crypto manager self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
when using the ccp-crypto driver:

alg: skcipher: cbc-des3-ccp encryption failed on test vector 0; expected_error=0, actual_error=-5 ...

alg: skcipher: ctr-aes-ccp decryption overran dst buffer on test vector 0 ...

alg: ahash: sha224-ccp test failed (wrong result) on test vector ...

These errors are the result of improper processing of scatterlists mapped
for DMA.

Given a scatterlist in which entries are merged as part of mapping the
scatterlist for DMA, the DMA length of a merged entry will reflect the
combined length of the entries that were merged. The subsequent
scatterlist entry will contain DMA information for the scatterlist entry
after the last merged entry, but the non-DMA information will be that of
the first merged entry.

The ccp driver does not take this scatterlist merging into account. To
address this, add a second scatterlist pointer to track the current
position in the DMA mapped representation of the scatterlist. Both the DMA
representation and the original representation of the scatterlist must be
tracked as while most of the driver can use just the DMA representation,
scatterlist_map_and_copy() must use the original representation and
expects the scatterlist pointer to be accurate to the original
representation.

In order to properly walk the original scatterlist, the scatterlist must
be walked until the combined lengths of the entries seen is equal to the
DMA length of the current entry being processed in the DMA mapped
representation.

Fixes: 63b945091a070 ("crypto: ccp - CCP device driver and interface support")
Signed-off-by: John Allen &lt;john.allen@amd.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8a302808c60d441d9884cb00ea7f2b534f2e3ca5 upstream.

Running the crypto manager self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
when using the ccp-crypto driver:

alg: skcipher: cbc-des3-ccp encryption failed on test vector 0; expected_error=0, actual_error=-5 ...

alg: skcipher: ctr-aes-ccp decryption overran dst buffer on test vector 0 ...

alg: ahash: sha224-ccp test failed (wrong result) on test vector ...

These errors are the result of improper processing of scatterlists mapped
for DMA.

Given a scatterlist in which entries are merged as part of mapping the
scatterlist for DMA, the DMA length of a merged entry will reflect the
combined length of the entries that were merged. The subsequent
scatterlist entry will contain DMA information for the scatterlist entry
after the last merged entry, but the non-DMA information will be that of
the first merged entry.

The ccp driver does not take this scatterlist merging into account. To
address this, add a second scatterlist pointer to track the current
position in the DMA mapped representation of the scatterlist. Both the DMA
representation and the original representation of the scatterlist must be
tracked as while most of the driver can use just the DMA representation,
scatterlist_map_and_copy() must use the original representation and
expects the scatterlist pointer to be accurate to the original
representation.

In order to properly walk the original scatterlist, the scatterlist must
be walked until the combined lengths of the entries seen is equal to the
DMA length of the current entry being processed in the DMA mapped
representation.

Fixes: 63b945091a070 ("crypto: ccp - CCP device driver and interface support")
Signed-off-by: John Allen &lt;john.allen@amd.com&gt;
Cc: stable@vger.kernel.org
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Release all allocated memory if sha type is invalid</title>
<updated>2020-08-21T09:01:47+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-09-19T16:04:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65d77c8771d2246fafb8e57dd260c8fa7224a576'/>
<id>65d77c8771d2246fafb8e57dd260c8fa7224a576</id>
<content type='text'>
[ Upstream commit 128c66429247add5128c03dc1e144ca56f05a4e2 ]

Release all allocated memory if sha type is invalid:
In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
hmac_buf should be released.

v2: fix the goto.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 128c66429247add5128c03dc1e144ca56f05a4e2 ]

Release all allocated memory if sha type is invalid:
In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
hmac_buf should be released.

v2: fix the goto.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - fix AES CFB error exposed by new test vectors</title>
<updated>2020-01-29T09:24:25+00:00</updated>
<author>
<name>Hook, Gary</name>
<email>Gary.Hook@amd.com</email>
</author>
<published>2019-05-14T21:53:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b55ca259c2a1d845efa048eaffd52d0ba01ee360'/>
<id>b55ca259c2a1d845efa048eaffd52d0ba01ee360</id>
<content type='text'>
[ Upstream commit c3b359d6567c0b8f413e924feb37cf025067d55a ]

Updated testmgr will exhibit this error message when loading the
ccp-crypto module:

alg: skcipher: cfb-aes-ccp encryption failed with err -22 on test vector 3, cfg="in-place"

Update the CCP crypto driver to correctly treat CFB as a streaming mode
cipher (instead of block mode). Update the configuration for CFB to
specify the block size as a single byte;

Fixes: 2b789435d7f3 ('crypto: ccp - CCP AES crypto API support')

Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c3b359d6567c0b8f413e924feb37cf025067d55a ]

Updated testmgr will exhibit this error message when loading the
ccp-crypto module:

alg: skcipher: cfb-aes-ccp encryption failed with err -22 on test vector 3, cfg="in-place"

Update the CCP crypto driver to correctly treat CFB as a streaming mode
cipher (instead of block mode). Update the configuration for CFB to
specify the block size as a single byte;

Fixes: 2b789435d7f3 ('crypto: ccp - CCP AES crypto API support')

Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - fix uninitialized list head</title>
<updated>2019-12-21T09:41:40+00:00</updated>
<author>
<name>Mark Salter</name>
<email>msalter@redhat.com</email>
</author>
<published>2019-10-21T15:29:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d63fe94b0c7223a4f0405431ee2ced62be441bee'/>
<id>d63fe94b0c7223a4f0405431ee2ced62be441bee</id>
<content type='text'>
commit 691505a803a7f223b2af621848d581259c61f77d upstream.

A NULL-pointer dereference was reported in fedora bz#1762199 while
reshaping a raid6 array after adding a fifth drive to an existing
array.

[   47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2
[   47.804017] md0: detected capacity change from 0 to 7885289422848
[   47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000
...
[   47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G        W         5.2.18-200.fc30.aarch64 #1
[   47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016
[   47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO)
[   47.963668] pc : __list_del_entry_valid+0x2c/0xa8
[   47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp]
[   47.972882] sp : ffff00001369b970
[   47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8
[   47.981483] x27: 00000000ffffffff x26: ffff8003b758af70
[   47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818
[   47.992080] x23: 0000000000000000 x22: ffff8003e62450c0
[   47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003
[   48.002678] x19: ffff8003e6245100 x18: 0000000000000000
[   48.007976] x17: 0000000000000000 x16: 0000000000000000
[   48.013274] x15: 0000000000000000 x14: 0000000000000000
[   48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001
[   48.023870] x11: ffff000010eff998 x10: 00000000000019a0
[   48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180
[   48.034467] x7 : 0000000000000000 x6 : 000000000000003f
[   48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080
[   48.045064] x3 : dead000000000200 x2 : 0000000000000000
[   48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0
[   48.055660] Call trace:
[   48.058095]  __list_del_entry_valid+0x2c/0xa8
[   48.062442]  ccp_tx_submit+0x84/0x168 [ccp]
[   48.066615]  async_tx_submit+0x224/0x368 [async_tx]
[   48.071480]  async_trigger_callback+0x68/0xfc [async_tx]
[   48.076784]  ops_run_biofill+0x178/0x1e8 [raid456]
[   48.081566]  raid_run_ops+0x248/0x818 [raid456]
[   48.086086]  handle_stripe+0x864/0x1208 [raid456]
[   48.090781]  handle_active_stripes.isra.0+0xb0/0x278 [raid456]
[   48.096604]  raid5d+0x378/0x618 [raid456]
[   48.100602]  md_thread+0xa0/0x150
[   48.103905]  kthread+0x104/0x130
[   48.107122]  ret_from_fork+0x10/0x18
[   48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021)
[   48.116766] ---[ end trace 23f390a527f7ad77 ]---

ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in
a ccp_dma_desc and adds it to a ccp channel's pending list:

	list_del(&amp;desc-&gt;entry);
	list_add_tail(&amp;desc-&gt;entry, &amp;chan-&gt;pending);

The problem is that desc-&gt;entry may be uninitialized in the
async_trigger_callback path where the descriptor was gotten
from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc
which doesn't initialize the desc-&gt;entry list head. So, just
initialize the list head to avoid the problem.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Sahaj Sarup &lt;sahajsarup@gmail.com&gt;
Signed-off-by: Mark Salter &lt;msalter@redhat.com&gt;
Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 691505a803a7f223b2af621848d581259c61f77d upstream.

A NULL-pointer dereference was reported in fedora bz#1762199 while
reshaping a raid6 array after adding a fifth drive to an existing
array.

[   47.343549] md/raid:md0: raid level 6 active with 3 out of 5 devices, algorithm 2
[   47.804017] md0: detected capacity change from 0 to 7885289422848
[   47.822083] Unable to handle kernel read from unreadable memory at virtual address 0000000000000000
...
[   47.940477] CPU: 1 PID: 14210 Comm: md0_raid6 Tainted: G        W         5.2.18-200.fc30.aarch64 #1
[   47.949594] Hardware name: AMD Overdrive/Supercharger/To be filled by O.E.M., BIOS ROD1002C 04/08/2016
[   47.958886] pstate: 00400085 (nzcv daIf +PAN -UAO)
[   47.963668] pc : __list_del_entry_valid+0x2c/0xa8
[   47.968366] lr : ccp_tx_submit+0x84/0x168 [ccp]
[   47.972882] sp : ffff00001369b970
[   47.976184] x29: ffff00001369b970 x28: ffff00001369bdb8
[   47.981483] x27: 00000000ffffffff x26: ffff8003b758af70
[   47.986782] x25: ffff8003b758b2d8 x24: ffff8003e6245818
[   47.992080] x23: 0000000000000000 x22: ffff8003e62450c0
[   47.997379] x21: ffff8003dfd6add8 x20: 0000000000000003
[   48.002678] x19: ffff8003e6245100 x18: 0000000000000000
[   48.007976] x17: 0000000000000000 x16: 0000000000000000
[   48.013274] x15: 0000000000000000 x14: 0000000000000000
[   48.018572] x13: ffff7e000ef83a00 x12: 0000000000000001
[   48.023870] x11: ffff000010eff998 x10: 00000000000019a0
[   48.029169] x9 : 0000000000000000 x8 : ffff8003e6245180
[   48.034467] x7 : 0000000000000000 x6 : 000000000000003f
[   48.039766] x5 : 0000000000000040 x4 : ffff8003e0145080
[   48.045064] x3 : dead000000000200 x2 : 0000000000000000
[   48.050362] x1 : 0000000000000000 x0 : ffff8003e62450c0
[   48.055660] Call trace:
[   48.058095]  __list_del_entry_valid+0x2c/0xa8
[   48.062442]  ccp_tx_submit+0x84/0x168 [ccp]
[   48.066615]  async_tx_submit+0x224/0x368 [async_tx]
[   48.071480]  async_trigger_callback+0x68/0xfc [async_tx]
[   48.076784]  ops_run_biofill+0x178/0x1e8 [raid456]
[   48.081566]  raid_run_ops+0x248/0x818 [raid456]
[   48.086086]  handle_stripe+0x864/0x1208 [raid456]
[   48.090781]  handle_active_stripes.isra.0+0xb0/0x278 [raid456]
[   48.096604]  raid5d+0x378/0x618 [raid456]
[   48.100602]  md_thread+0xa0/0x150
[   48.103905]  kthread+0x104/0x130
[   48.107122]  ret_from_fork+0x10/0x18
[   48.110686] Code: d2804003 f2fbd5a3 eb03003f 54000320 (f9400021)
[   48.116766] ---[ end trace 23f390a527f7ad77 ]---

ccp_tx_submit is passed a dma_async_tx_descriptor which is contained in
a ccp_dma_desc and adds it to a ccp channel's pending list:

	list_del(&amp;desc-&gt;entry);
	list_add_tail(&amp;desc-&gt;entry, &amp;chan-&gt;pending);

The problem is that desc-&gt;entry may be uninitialized in the
async_trigger_callback path where the descriptor was gotten
from ccp_prep_dma_interrupt which got it from ccp_alloc_dma_desc
which doesn't initialize the desc-&gt;entry list head. So, just
initialize the list head to avoid the problem.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Sahaj Sarup &lt;sahajsarup@gmail.com&gt;
Signed-off-by: Mark Salter &lt;msalter@redhat.com&gt;
Acked-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Validate the the error value used to index error messages</title>
<updated>2019-08-04T07:33:30+00:00</updated>
<author>
<name>Hook, Gary</name>
<email>Gary.Hook@amd.com</email>
</author>
<published>2019-06-27T16:16:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=029cc4f0f075de930e9a4ee13e73c4d37b1fecd9'/>
<id>029cc4f0f075de930e9a4ee13e73c4d37b1fecd9</id>
<content type='text'>
commit 52393d617af7b554f03531e6756facf2ea687d2e upstream.

The error code read from the queue status register is only 6 bits wide,
but we need to verify its value is within range before indexing the error
messages.

Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Cfir Cohen &lt;cfir@google.com&gt;
Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 52393d617af7b554f03531e6756facf2ea687d2e upstream.

The error code read from the queue status register is only 6 bits wide,
but we need to verify its value is within range before indexing the error
messages.

Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable")
Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: Cfir Cohen &lt;cfir@google.com&gt;
Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Set the AES size field for all modes</title>
<updated>2017-11-08T09:08:33+00:00</updated>
<author>
<name>Gary R Hook</name>
<email>gary.hook@amd.com</email>
</author>
<published>2017-10-07T22:36:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=58b9a54ae03d9fecaaaea83a08098b2aeae41201'/>
<id>58b9a54ae03d9fecaaaea83a08098b2aeae41201</id>
<content type='text'>
[ Upstream commit f7cc02b3c3a33a10dd5bb9e5dfd22e47e09503a2 ]

Ensure that the size field is correctly populated for
all AES modes.

Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f7cc02b3c3a33a10dd5bb9e5dfd22e47e09503a2 ]

Ensure that the size field is correctly populated for
all AES modes.

Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Fix XTS-AES-128 support on v5 CCPs</title>
<updated>2017-09-27T12:39:20+00:00</updated>
<author>
<name>Gary R Hook</name>
<email>gary.hook@amd.com</email>
</author>
<published>2017-07-25T19:12:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dcb3a4b8d7768cab59546aa2ce5dd214f7b526fe'/>
<id>dcb3a4b8d7768cab59546aa2ce5dd214f7b526fe</id>
<content type='text'>
commit e652399edba99a5497f0d80f240c9075d3b43493 upstream.

Version 5 CCPs have some new requirements for XTS-AES: the type field
must be specified, and the key requires 512 bits, with each part
occupying 256 bits and padded with zeroes.

Signed-off-by: Gary R Hook &lt;ghook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e652399edba99a5497f0d80f240c9075d3b43493 upstream.

Version 5 CCPs have some new requirements for XTS-AES: the type field
must be specified, and the key requires 512 bits, with each part
occupying 256 bits and padded with zeroes.

Signed-off-by: Gary R Hook &lt;ghook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>crypto: ccp - Change ISR handler method for a v5 CCP</title>
<updated>2017-05-20T12:28:37+00:00</updated>
<author>
<name>Gary R Hook</name>
<email>gary.hook@amd.com</email>
</author>
<published>2017-04-21T15:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f8d05099ec72a943a71b2c95959d37dbef13b7f1'/>
<id>f8d05099ec72a943a71b2c95959d37dbef13b7f1</id>
<content type='text'>
commit 6263b51eb3190d30351360fd168959af7e3a49a9 upstream.

The CCP has the ability to perform several operations simultaneously,
but only one interrupt.  When implemented as a PCI device and using
MSI-X/MSI interrupts, use a tasklet model to service interrupts. By
disabling and enabling interrupts from the CCP, coupled with the
queuing that tasklets provide, we can ensure that all events
(occurring on the device) are recognized and serviced.

This change fixes a problem wherein 2 or more busy queues can cause
notification bits to change state while a (CCP) interrupt is being
serviced, but after the queue state has been evaluated. This results
in the event being 'lost' and the queue hanging, waiting to be
serviced. Since the status bits are never fully de-asserted, the
CCP never generates another interrupt (all bits zero -&gt; one or more
bits one), and no further CCP operations will be executed.

Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6263b51eb3190d30351360fd168959af7e3a49a9 upstream.

The CCP has the ability to perform several operations simultaneously,
but only one interrupt.  When implemented as a PCI device and using
MSI-X/MSI interrupts, use a tasklet model to service interrupts. By
disabling and enabling interrupts from the CCP, coupled with the
queuing that tasklets provide, we can ensure that all events
(occurring on the device) are recognized and serviced.

This change fixes a problem wherein 2 or more busy queues can cause
notification bits to change state while a (CCP) interrupt is being
serviced, but after the queue state has been evaluated. This results
in the event being 'lost' and the queue hanging, waiting to be
serviced. Since the status bits are never fully de-asserted, the
CCP never generates another interrupt (all bits zero -&gt; one or more
bits one), and no further CCP operations will be executed.

Signed-off-by: Gary R Hook &lt;gary.hook@amd.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
