linux-toradex.git/drivers/crypto/omap-aes.c, branch v6.3-rc3

crypto: omap-aes - Drop if with an always false condition

2022-07-15T08:43:21+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap-aes - Constify static attribute_group

2022-02-18T05:21:09+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap-aes - Fix broken pm_runtime_and_get() usage

2021-12-24T03:18:28+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap - Fix inconsistent locking of device lists

2021-08-21T07:44:53+00:00

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): [] __kmalloc+0x484/0x5ec
    hardirqs last disabled at (111799): [] __kmalloc+0x490/0x5ec
    softirqs last  enabled at (111776): [] __do_softirq+0x2b8/0x4d0
    softirqs last disabled at (111781): [] run_ksoftirqd+0x34/0x50

    other info that might help us debug this:
     Possible unsafe locking scenario:

           CPU0
           ----
      lock(list_lock);
      
        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)
    [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
    [] (show_stack) from [] (mark_lock.part.17+0x5bc/0xd04)
    [] (mark_lock.part.17) from [] (__lock_acquire+0x960/0x2fa4)
    [] (__lock_acquire) from [] (lock_acquire+0x10c/0x358)
    [] (lock_acquire) from [] (_raw_spin_lock_bh+0x44/0x58)
    [] (_raw_spin_lock_bh) from [] (omap_aes_find_dev+0x18/0x54 [omap_aes_driver])
    [] (omap_aes_find_dev [omap_aes_driver]) from [] (omap_aes_crypt+0x94/0xd4 [omap_aes_driver])
    [] (omap_aes_crypt [omap_aes_driver]) from [] (esp_input+0x1b0/0x2c8)
    [] (esp_input) from [] (xfrm_input+0x410/0x1290)
    [] (xfrm_input) from [] (xfrm4_esp_rcv+0x54/0x11c)
    [] (xfrm4_esp_rcv) from [] (ip_protocol_deliver_rcu+0x48/0x3bc)
    [] (ip_protocol_deliver_rcu) from [] (ip_local_deliver_finish+0x9c/0xdc)
    [] (ip_local_deliver_finish) from [] (ip_local_deliver+0x148/0x1b0)
    [] (ip_local_deliver) from [] (ip_rcv+0x11c/0x180)
    [] (ip_rcv) from [] (__netif_receive_skb_one_core+0x54/0x74)
    [] (__netif_receive_skb_one_core) from [] (netif_receive_skb+0xa8/0x260)
    [] (netif_receive_skb) from [] (cpsw_rx_handler+0x224/0x2fc)
    [] (cpsw_rx_handler) from [] (__cpdma_chan_process+0xf4/0x188)
    [] (__cpdma_chan_process) from [] (cpdma_chan_process+0x3c/0x5c)
    [] (cpdma_chan_process) from [] (cpsw_rx_mq_poll+0x44/0x98)
    [] (cpsw_rx_mq_poll) from [] (__napi_poll+0x28/0x268)
    [] (__napi_poll) from [] (net_rx_action+0xcc/0x204)
    [] (net_rx_action) from [] (__do_softirq+0x140/0x4d0)
    [] (__do_softirq) from [] (run_ksoftirqd+0x34/0x50)
    [] (run_ksoftirqd) from [] (smpboot_thread_fn+0xf4/0x1d8)
    [] (smpboot_thread_fn) from [] (kthread+0x14c/0x174)
    [] (kthread) from [] (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 
Signed-off-by: Herbert Xu

crypto: omap-aes - Fix PM reference leak on omap-aes.c

2021-04-16T11:16:33+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap-aes - Fix PM disable depth imbalance in omap_aes_probe

2020-11-20T03:45:34+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap-aes - fix the reference count leak of omap device

2020-10-30T06:35:02+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap-aes - Fix sparse and compiler warnings

2020-07-23T07:34:19+00:00

This patch fixes all the sparse and W=1 compiler warnings in the
driver.

Signed-off-by: Herbert Xu

crypto: omap-aes - permit asynchronous skcipher as fallback

2020-07-16T11:49:02+00:00

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 
Signed-off-by: Herbert Xu

crypto: omap-aes - prevent unregistering algorithms twice

2020-06-04T12:03:42+00:00

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 
Signed-off-by: Herbert Xu