Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
b0cc7491 |
| 14-Jul-2023 |
Rob Herring <robh@kernel.org> |
crypto: drivers - Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As par
crypto: drivers - Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
03906fba |
| 13-Aug-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: omap - Use new crypto_engine_op interface
Use the new crypto_engine_op interface where the callback is stored in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
#
b7b23ccb |
| 13-Aug-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: omap - Include internal/engine.h
Inlucde internal/engine.h because this driver uses directly accesses attributes inside struct crypto_engine.
Signed-off-by: Herbert Xu <herbert@gondor.apana
crypto: omap - Include internal/engine.h
Inlucde internal/engine.h because this driver uses directly accesses attributes inside struct crypto_engine.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
c752c013 |
| 13-Aug-2023 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: omap - Remove prepare/unprepare request
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request.
Move the code into d
crypto: omap - Remove prepare/unprepare request
The callbacks for prepare and unprepare request in crypto_engine is superfluous. They can be done directly from do_one_request.
Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53 |
|
#
da1e7168 |
| 05-Jul-2022 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
crypto: omap-aes - Drop if with an always false condition
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argume
crypto: omap-aes - Drop if with an always false condition
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so dd is never NULL.
This is a preparation for making platform remove callbacks return void.
While touching this driver remove a stray empty line.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23 |
|
#
882f6c60 |
| 10-Feb-2022 |
Rikard Falkeborn <rikard.falkeborn@gmail.com> |
crypto: omap-aes - Constify static attribute_group
The only usage of omap_aes_attr_group is to pass its address to sysfs_{create,remove}_group(), which takes pointers to const struct attribute_group
crypto: omap-aes - Constify static attribute_group
The only usage of omap_aes_attr_group is to pass its address to sysfs_{create,remove}_group(), which takes pointers to const struct attribute_group. Make it const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10 |
|
#
c2aec59b |
| 17-Dec-2021 |
Heiner Kallweit <hkallweit1@gmail.com> |
crypto: omap-aes - Fix broken pm_runtime_and_get() usage
This fix is basically the same as 3d6b661330a7 ("crypto: stm32 - Revert broken pm_runtime_resume_and_get changes"), just for the omap driver.
crypto: omap-aes - Fix broken pm_runtime_and_get() usage
This fix is basically the same as 3d6b661330a7 ("crypto: stm32 - Revert broken pm_runtime_resume_and_get changes"), just for the omap driver. If the return value isn't used, then pm_runtime_get_sync() has to be used for ensuring that the usage count is balanced.
Fixes: 1f34cc4a8da3 ("crypto: omap-aes - Fix PM reference leak on omap-aes.c") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
7f429ce7 |
| 17-Dec-2021 |
Heiner Kallweit <hkallweit1@gmail.com> |
crypto: omap-aes - Fix broken pm_runtime_and_get() usage
commit c2aec59be093bd44627bc4f6bc67e4614a93a7b6 upstream.
This fix is basically the same as 3d6b661330a7 ("crypto: stm32 - Revert broken pm_
crypto: omap-aes - Fix broken pm_runtime_and_get() usage
commit c2aec59be093bd44627bc4f6bc67e4614a93a7b6 upstream.
This fix is basically the same as 3d6b661330a7 ("crypto: stm32 - Revert broken pm_runtime_resume_and_get changes"), just for the omap driver. If the return value isn't used, then pm_runtime_get_sync() has to be used for ensuring that the usage count is balanced.
Fixes: 1f34cc4a8da3 ("crypto: omap-aes - Fix PM reference leak on omap-aes.c") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
fe4d5577 |
| 10-Aug-2021 |
Ben Hutchings <ben.hutchings@mind.be> |
crypto: omap - Fix inconsistent locking of device lists
lockdep complains that in omap-aes, the list_lock is taken both with softirqs enabled at probe time, and also in softirq context, which could
crypto: omap - Fix inconsistent locking of device lists
lockdep complains that in omap-aes, the list_lock is taken both with softirqs enabled at probe time, and also in softirq context, which could lead to a deadlock:
================================ WARNING: inconsistent lock state 5.14.0-rc1-00035-gc836005b01c5-dirty #69 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/0/7 [HC0[0]:SC1[3]:HE1:SE0] takes: bf00e014 (list_lock){+.?.}-{2:2}, at: omap_aes_find_dev+0x18/0x54 [omap_aes_driver] {SOFTIRQ-ON-W} state was registered at: _raw_spin_lock+0x40/0x50 omap_aes_probe+0x1d4/0x664 [omap_aes_driver] platform_probe+0x58/0xb8 really_probe+0xbc/0x314 __driver_probe_device+0x80/0xe4 driver_probe_device+0x30/0xc8 __driver_attach+0x70/0xf4 bus_for_each_dev+0x70/0xb4 bus_add_driver+0xf0/0x1d4 driver_register+0x74/0x108 do_one_initcall+0x84/0x2e4 do_init_module+0x5c/0x240 load_module+0x221c/0x2584 sys_finit_module+0xb0/0xec ret_fast_syscall+0x0/0x2c 0xbed90b30 irq event stamp: 111800 hardirqs last enabled at (111800): [<c02a21e4>] __kmalloc+0x484/0x5ec hardirqs last disabled at (111799): [<c02a21f0>] __kmalloc+0x490/0x5ec softirqs last enabled at (111776): [<c01015f0>] __do_softirq+0x2b8/0x4d0 softirqs last disabled at (111781): [<c0135948>] run_ksoftirqd+0x34/0x50
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(list_lock); <Interrupt> lock(list_lock);
*** DEADLOCK ***
2 locks held by ksoftirqd/0/7: #0: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: netif_receive_skb+0x6c/0x260 #1: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0x2c/0xdc
stack backtrace: CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 5.14.0-rc1-00035-gc836005b01c5-dirty #69 Hardware name: Generic AM43 (Flattened Device Tree) [<c010e6e0>] (unwind_backtrace) from [<c010b9d0>] (show_stack+0x10/0x14) [<c010b9d0>] (show_stack) from [<c017c640>] (mark_lock.part.17+0x5bc/0xd04) [<c017c640>] (mark_lock.part.17) from [<c017d9e4>] (__lock_acquire+0x960/0x2fa4) [<c017d9e4>] (__lock_acquire) from [<c0180980>] (lock_acquire+0x10c/0x358) [<c0180980>] (lock_acquire) from [<c093d324>] (_raw_spin_lock_bh+0x44/0x58) [<c093d324>] (_raw_spin_lock_bh) from [<bf00b258>] (omap_aes_find_dev+0x18/0x54 [omap_aes_driver]) [<bf00b258>] (omap_aes_find_dev [omap_aes_driver]) from [<bf00b328>] (omap_aes_crypt+0x94/0xd4 [omap_aes_driver]) [<bf00b328>] (omap_aes_crypt [omap_aes_driver]) from [<c08ac6d0>] (esp_input+0x1b0/0x2c8) [<c08ac6d0>] (esp_input) from [<c08c9e90>] (xfrm_input+0x410/0x1290) [<c08c9e90>] (xfrm_input) from [<c08b6374>] (xfrm4_esp_rcv+0x54/0x11c) [<c08b6374>] (xfrm4_esp_rcv) from [<c0838840>] (ip_protocol_deliver_rcu+0x48/0x3bc) [<c0838840>] (ip_protocol_deliver_rcu) from [<c0838c50>] (ip_local_deliver_finish+0x9c/0xdc) [<c0838c50>] (ip_local_deliver_finish) from [<c0838dd8>] (ip_local_deliver+0x148/0x1b0) [<c0838dd8>] (ip_local_deliver) from [<c0838f5c>] (ip_rcv+0x11c/0x180) [<c0838f5c>] (ip_rcv) from [<c077e3a4>] (__netif_receive_skb_one_core+0x54/0x74) [<c077e3a4>] (__netif_receive_skb_one_core) from [<c077e588>] (netif_receive_skb+0xa8/0x260) [<c077e588>] (netif_receive_skb) from [<c068d6d4>] (cpsw_rx_handler+0x224/0x2fc) [<c068d6d4>] (cpsw_rx_handler) from [<c0688ccc>] (__cpdma_chan_process+0xf4/0x188) [<c0688ccc>] (__cpdma_chan_process) from [<c068a0c0>] (cpdma_chan_process+0x3c/0x5c) [<c068a0c0>] (cpdma_chan_process) from [<c0690e14>] (cpsw_rx_mq_poll+0x44/0x98) [<c0690e14>] (cpsw_rx_mq_poll) from [<c0780810>] (__napi_poll+0x28/0x268) [<c0780810>] (__napi_poll) from [<c0780c64>] (net_rx_action+0xcc/0x204) [<c0780c64>] (net_rx_action) from [<c0101478>] (__do_softirq+0x140/0x4d0) [<c0101478>] (__do_softirq) from [<c0135948>] (run_ksoftirqd+0x34/0x50) [<c0135948>] (run_ksoftirqd) from [<c01583b8>] (smpboot_thread_fn+0xf4/0x1d8) [<c01583b8>] (smpboot_thread_fn) from [<c01546dc>] (kthread+0x14c/0x174) [<c01546dc>] (kthread) from [<c010013c>] (ret_from_fork+0x14/0x38) ...
The omap-des and omap-sham drivers appear to have a similar issue.
Fix this by using spin_{,un}lock_bh() around device list access in all the probe and remove functions.
Signed-off-by: Ben Hutchings <ben.hutchings@mind.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
1f34cc4a |
| 08-Apr-2021 |
Shixin Liu <liushixin2@huawei.com> |
crypto: omap-aes - Fix PM reference leak on omap-aes.c
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it
crypto: omap-aes - Fix PM reference leak on omap-aes.c
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
ff810720 |
| 13-Nov-2020 |
Zhang Qilong <zhangqilong3@huawei.com> |
crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe
The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it
crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe
The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context.
Fixes: f7b2b5dd6a62a ("crypto: omap-aes - add error check for pm_runtime_get_sync") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.8.17, v5.8.16 |
|
#
383e8a82 |
| 16-Oct-2020 |
Zhang Qilong <zhangqilong3@huawei.com> |
crypto: omap-aes - fix the reference count leak of omap device
pm_runtime_get_sync() will increment pm usage counter even when it returns an error code. We should call put operation in error handli
crypto: omap-aes - fix the reference count leak of omap device
pm_runtime_get_sync() will increment pm usage counter even when it returns an error code. We should call put operation in error handling paths of omap_aes_hw_init.
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
6f3c58bd |
| 10-Aug-2021 |
Ben Hutchings <ben.hutchings@mind.be> |
crypto: omap - Fix inconsistent locking of device lists
[ Upstream commit fe4d55773b879c785ae61da9b1c2160f0110f67e ]
lockdep complains that in omap-aes, the list_lock is taken both with softirqs en
crypto: omap - Fix inconsistent locking of device lists
[ Upstream commit fe4d55773b879c785ae61da9b1c2160f0110f67e ]
lockdep complains that in omap-aes, the list_lock is taken both with softirqs enabled at probe time, and also in softirq context, which could lead to a deadlock:
================================ WARNING: inconsistent lock state 5.14.0-rc1-00035-gc836005b01c5-dirty #69 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/0/7 [HC0[0]:SC1[3]:HE1:SE0] takes: bf00e014 (list_lock){+.?.}-{2:2}, at: omap_aes_find_dev+0x18/0x54 [omap_aes_driver] {SOFTIRQ-ON-W} state was registered at: _raw_spin_lock+0x40/0x50 omap_aes_probe+0x1d4/0x664 [omap_aes_driver] platform_probe+0x58/0xb8 really_probe+0xbc/0x314 __driver_probe_device+0x80/0xe4 driver_probe_device+0x30/0xc8 __driver_attach+0x70/0xf4 bus_for_each_dev+0x70/0xb4 bus_add_driver+0xf0/0x1d4 driver_register+0x74/0x108 do_one_initcall+0x84/0x2e4 do_init_module+0x5c/0x240 load_module+0x221c/0x2584 sys_finit_module+0xb0/0xec ret_fast_syscall+0x0/0x2c 0xbed90b30 irq event stamp: 111800 hardirqs last enabled at (111800): [<c02a21e4>] __kmalloc+0x484/0x5ec hardirqs last disabled at (111799): [<c02a21f0>] __kmalloc+0x490/0x5ec softirqs last enabled at (111776): [<c01015f0>] __do_softirq+0x2b8/0x4d0 softirqs last disabled at (111781): [<c0135948>] run_ksoftirqd+0x34/0x50
other info that might help us debug this: Possible unsafe locking scenario:
CPU0 ---- lock(list_lock); <Interrupt> lock(list_lock);
*** DEADLOCK ***
2 locks held by ksoftirqd/0/7: #0: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: netif_receive_skb+0x6c/0x260 #1: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0x2c/0xdc
stack backtrace: CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 5.14.0-rc1-00035-gc836005b01c5-dirty #69 Hardware name: Generic AM43 (Flattened Device Tree) [<c010e6e0>] (unwind_backtrace) from [<c010b9d0>] (show_stack+0x10/0x14) [<c010b9d0>] (show_stack) from [<c017c640>] (mark_lock.part.17+0x5bc/0xd04) [<c017c640>] (mark_lock.part.17) from [<c017d9e4>] (__lock_acquire+0x960/0x2fa4) [<c017d9e4>] (__lock_acquire) from [<c0180980>] (lock_acquire+0x10c/0x358) [<c0180980>] (lock_acquire) from [<c093d324>] (_raw_spin_lock_bh+0x44/0x58) [<c093d324>] (_raw_spin_lock_bh) from [<bf00b258>] (omap_aes_find_dev+0x18/0x54 [omap_aes_driver]) [<bf00b258>] (omap_aes_find_dev [omap_aes_driver]) from [<bf00b328>] (omap_aes_crypt+0x94/0xd4 [omap_aes_driver]) [<bf00b328>] (omap_aes_crypt [omap_aes_driver]) from [<c08ac6d0>] (esp_input+0x1b0/0x2c8) [<c08ac6d0>] (esp_input) from [<c08c9e90>] (xfrm_input+0x410/0x1290) [<c08c9e90>] (xfrm_input) from [<c08b6374>] (xfrm4_esp_rcv+0x54/0x11c) [<c08b6374>] (xfrm4_esp_rcv) from [<c0838840>] (ip_protocol_deliver_rcu+0x48/0x3bc) [<c0838840>] (ip_protocol_deliver_rcu) from [<c0838c50>] (ip_local_deliver_finish+0x9c/0xdc) [<c0838c50>] (ip_local_deliver_finish) from [<c0838dd8>] (ip_local_deliver+0x148/0x1b0) [<c0838dd8>] (ip_local_deliver) from [<c0838f5c>] (ip_rcv+0x11c/0x180) [<c0838f5c>] (ip_rcv) from [<c077e3a4>] (__netif_receive_skb_one_core+0x54/0x74) [<c077e3a4>] (__netif_receive_skb_one_core) from [<c077e588>] (netif_receive_skb+0xa8/0x260) [<c077e588>] (netif_receive_skb) from [<c068d6d4>] (cpsw_rx_handler+0x224/0x2fc) [<c068d6d4>] (cpsw_rx_handler) from [<c0688ccc>] (__cpdma_chan_process+0xf4/0x188) [<c0688ccc>] (__cpdma_chan_process) from [<c068a0c0>] (cpdma_chan_process+0x3c/0x5c) [<c068a0c0>] (cpdma_chan_process) from [<c0690e14>] (cpsw_rx_mq_poll+0x44/0x98) [<c0690e14>] (cpsw_rx_mq_poll) from [<c0780810>] (__napi_poll+0x28/0x268) [<c0780810>] (__napi_poll) from [<c0780c64>] (net_rx_action+0xcc/0x204) [<c0780c64>] (net_rx_action) from [<c0101478>] (__do_softirq+0x140/0x4d0) [<c0101478>] (__do_softirq) from [<c0135948>] (run_ksoftirqd+0x34/0x50) [<c0135948>] (run_ksoftirqd) from [<c01583b8>] (smpboot_thread_fn+0xf4/0x1d8) [<c01583b8>] (smpboot_thread_fn) from [<c01546dc>] (kthread+0x14c/0x174) [<c01546dc>] (kthread) from [<c010013c>] (ret_from_fork+0x14/0x38) ...
The omap-des and omap-sham drivers appear to have a similar issue.
Fix this by using spin_{,un}lock_bh() around device list access in all the probe and remove functions.
Signed-off-by: Ben Hutchings <ben.hutchings@mind.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
5d60792d |
| 08-Apr-2021 |
Shixin Liu <liushixin2@huawei.com> |
crypto: omap-aes - Fix PM reference leak on omap-aes.c
[ Upstream commit 1f34cc4a8da34fbb250efb928f9b8c6fe7ee0642 ]
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to
crypto: omap-aes - Fix PM reference leak on omap-aes.c
[ Upstream commit 1f34cc4a8da34fbb250efb928f9b8c6fe7ee0642 ]
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced.
Signed-off-by: Shixin Liu <liushixin2@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
3cf33a46 |
| 13-Nov-2020 |
Zhang Qilong <zhangqilong3@huawei.com> |
crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe
[ Upstream commit ff8107200367f4abe0e5bce66a245e8d0f2d229e ]
The pm_runtime_enable will increase power disable depth. Thus a pair
crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe
[ Upstream commit ff8107200367f4abe0e5bce66a245e8d0f2d229e ]
The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context.
Fixes: f7b2b5dd6a62a ("crypto: omap-aes - add error check for pm_runtime_get_sync") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53 |
|
#
ac855b3c |
| 16-Jul-2020 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: omap-aes - Fix sparse and compiler warnings
This patch fixes all the sparse and W=1 compiler warnings in the driver.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
Revision tags: v5.4.52, v5.7.9, v5.7.8, v5.4.51 |
|
#
6a99d7a2 |
| 07-Jul-2020 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: omap-aes - permit asynchronous skcipher as fallback
Even though the omap-aes driver implements asynchronous versions of ecb(aes), cbc(aes) and ctr(aes), the fallbacks it allocates are requir
crypto: omap-aes - permit asynchronous skcipher as fallback
Even though the omap-aes driver implements asynchronous versions of ecb(aes), cbc(aes) and ctr(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead.
Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
9ef4e6e5 |
| 27-May-2020 |
Tero Kristo <t-kristo@ti.com> |
crypto: omap-aes - prevent unregistering algorithms twice
Most of the OMAP family SoCs contain two instances for AES core, which causes the remove callbacks to be also done twice when driver is remo
crypto: omap-aes - prevent unregistering algorithms twice
Most of the OMAP family SoCs contain two instances for AES core, which causes the remove callbacks to be also done twice when driver is removed. Fix the algorithm unregister callbacks to take into account the number of algorithms still registered to avoid removing these twice.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9 |
|
#
04a4616e |
| 05-Nov-2019 |
Tero Kristo <t-kristo@ti.com> |
crypto: omap-aes-gcm - convert to use crypto engine
Currently omap-aes-gcm algorithms are using local implementation for crypto request queuing logic. Instead, implement this via usage of crypto eng
crypto: omap-aes-gcm - convert to use crypto engine
Currently omap-aes-gcm algorithms are using local implementation for crypto request queuing logic. Instead, implement this via usage of crypto engine which is used already for rest of the omap aes algorithms. This avoids some random conflicts / crashes also which can happen if both aes and aes-gcm are attempted to be used simultaneously.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
5d5f3eed |
| 05-Nov-2019 |
Tero Kristo <t-kristo@ti.com> |
crypto: omap-aes-gcm - fix failure with assocdata only
If we only have assocdata with an omap-aes-gcm, it currently just completes it directly without passing it over to the crypto HW. This produces
crypto: omap-aes-gcm - fix failure with assocdata only
If we only have assocdata with an omap-aes-gcm, it currently just completes it directly without passing it over to the crypto HW. This produces wrong results.
Fix by passing the request down to the crypto HW, and fix the DMA support code to accept a case where we don't expect any output data. In the case where only assocdata is provided, it just passes through the accelerator and provides authentication results, without any encrypted/decrypted buffer via DMA.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
f0956d42 |
| 05-Nov-2019 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: omap-aes-gcm - use the AES library to encrypt the tag
The OMAP AES-GCM implementation uses a fallback ecb(aes) skcipher to produce the keystream to encrypt the output tag. Let's use the new
crypto: omap-aes-gcm - use the AES library to encrypt the tag
The OMAP AES-GCM implementation uses a fallback ecb(aes) skcipher to produce the keystream to encrypt the output tag. Let's use the new AES library instead - this is much simpler, and shouldn't affect performance given that it only involves a single block.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
12adf9d6 |
| 05-Nov-2019 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: omap-aes-gcm - add missing .setauthsize hooks
GCM only permits certain tag lengths, so populate the .setauthsize hooks which ensure that only permitted sizes are accepted by the implementati
crypto: omap-aes-gcm - add missing .setauthsize hooks
GCM only permits certain tag lengths, so populate the .setauthsize hooks which ensure that only permitted sizes are accepted by the implementation.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
a9459bdc |
| 05-Nov-2019 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: omap-aes-ctr - set blocksize to 1
CTR is a streamcipher mode of AES, so set the blocksize accordingly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Tero Kristo <t-kristo@ti.
crypto: omap-aes-ctr - set blocksize to 1
CTR is a streamcipher mode of AES, so set the blocksize accordingly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
dbb326fd |
| 05-Nov-2019 |
Ard Biesheuvel <ardb@kernel.org> |
crypto: omap-aes - reject invalid input sizes for block modes
Block modes such as ECB and CBC only support input sizes that are a round multiple of the block size, so align with the generic code whi
crypto: omap-aes - reject invalid input sizes for block modes
Block modes such as ECB and CBC only support input sizes that are a round multiple of the block size, so align with the generic code which returns -EINVAL when encountering inputs that violate this rule.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Tero Kristo <t-kristo@ti.com> Tested-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
6585cd36 |
| 05-Nov-2019 |
Tero Kristo <t-kristo@ti.com> |
crypto: omap-aes - fixup aligned data cleanup
Aligned data cleanup is using wrong pointers in the cleanup calls. Most of the time these are right, but can cause mysterious problems in some cases. Fi
crypto: omap-aes - fixup aligned data cleanup
Aligned data cleanup is using wrong pointers in the cleanup calls. Most of the time these are right, but can cause mysterious problems in some cases. Fix to use the same pointers that were used with the align call.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|