mbox series

[v5,00/21] Support more Amlogic SoC families in crypto driver

Message ID 20240301132936.621238-1-avromanov@salutedevices.com
Headers show
Series Support more Amlogic SoC families in crypto driver | expand

Message

Alexey Romanov March 1, 2024, 1:29 p.m. UTC 
Hello!

This patchset expand the funcionality of the Amlogic
crypto driver by adding support for more SoC families:
AXG, G12A, G12B, SM1, A1, S4.

Also specify and enable crypto node in device tree
for reference Amlogic devices.

Tested on GXL, AXG, G12A/B, SM1, A1 and S4 devices via
custom tests [1] and tcrypt module.

---

Changes V1 -> V2 [2]:

- Rebased over linux-next.
- Adjusted device tree bindings description.
- A1 and S4 dts use their own compatible, which is a G12 fallback.

Changes V2 -> V3 [3]:

- Fix errors in dt-bindings and device tree.
- Add new field in platform data, which determines
whether clock controller should be used for crypto IP.
- Place back MODULE_DEVICE_TABLE.
- Correct commit messages.

Changes V3 -> V4 [4]:

- Update dt-bindings as per Krzysztof Kozlowski comments.
- Fix bisection: get rid of compiler errors in some patches.

Changes V4 -> V5 [5]:

- Tested on GXL board:
  1. Fix panic detected by Corentin Labbe [6].
  2. Disable hasher backend for GXL: in its current realization
     is doesn't work. And there are no examples or docs in the
     vendor SDK.
- Fix AES-CTR realization: legacy boards (gxl, g12, axg) requires
  inversion of the keyiv at keys setup stage.
- A1 now uses its own compatible string.
- S4 uses A1 compatible as fallback.
- Code fixes based on comments Neil Atrmstrong and Rob Herring.
- Style fixes (set correct indentations)

Links:
  - [1] https://gist.github.com/mRrvz/3fb8943a7487ab7b943ec140706995e7
  - [2] https://lore.kernel.org/all/20240110201216.18016-1-avromanov@salutedevices.com/
  - [3] https://lore.kernel.org/all/20240123165831.970023-1-avromanov@salutedevices.com/
  - [4] https://lore.kernel.org/all/20240205155521.1795552-1-avromanov@salutedevices.com/
  - [5] https://lore.kernel.org/all/20240212135108.549755-1-avromanov@salutedevices.com/
  - [6] https://lore.kernel.org/all/ZcsYaPIUrBSg8iXu@Red/

Alexey Romanov (21):
  drivers: crypto: meson: don't hardcode IRQ count
  drviers: crypto: meson: add platform data
  drivers: crypto: meson: make CLK controller optional
  drivers: crypto: meson: add MMIO helpers
  drivers: crypto: meson: move get_engine_number()
  drivers: crypto: meson: drop status field from meson_flow
  drivers: crypto: meson: move algs definition and cipher API to
    cipher.c
  drivers: crypto: meson: cleanup defines
  drivers: crypto: meson: process more than MAXDESCS descriptors
  drivers: crypto: meson: avoid kzalloc in engine thread
  drivers: crypto: meson: introduce hasher
  drivers: crypto: meson: add support for AES-CTR
  drivers: crypto: meson: use fallback for 192-bit keys
  drivers: crypto: meson: add support for G12-series
  drivers: crypto: meson: add support for AXG-series
  drivers: crypto: meson: add support for A1-series
  dt-bindings: crypto: meson: support new SoC's
  arch: arm64: dts: meson: a1: add crypto node
  arch: arm64: dts: meson: s4: add crypto node
  arch: arm64: dts: meson: g12: add crypto node
  arch: arm64: dts: meson: axg: add crypto node

 .../bindings/crypto/amlogic,gxl-crypto.yaml   |  36 +-
 arch/arm64/boot/dts/amlogic/meson-a1.dtsi     |   7 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi    |   6 +
 .../boot/dts/amlogic/meson-g12-common.dtsi    |   6 +
 arch/arm64/boot/dts/amlogic/meson-s4.dtsi     |   6 +
 drivers/crypto/amlogic/Makefile               |   2 +-
 drivers/crypto/amlogic/amlogic-gxl-cipher.c   | 615 ++++++++++++------
 drivers/crypto/amlogic/amlogic-gxl-core.c     | 290 +++++----
 drivers/crypto/amlogic/amlogic-gxl-hasher.c   | 460 +++++++++++++
 drivers/crypto/amlogic/amlogic-gxl.h          | 118 +++-
 10 files changed, 1205 insertions(+), 341 deletions(-)
 create mode 100644 drivers/crypto/amlogic/amlogic-gxl-hasher.c

Comments

Jerome Brunet March 1, 2024, 3:21 p.m. UTC | #1 
On Fri 01 Mar 2024 at 16:29, Alexey Romanov <avromanov@salutedevices.com> wrote:

> Amlogic crypto IP doesn't take a clock input on some
> SoCs: AXG / A1 / S4 / G12. So make it optional.
>

I commented this patch on v2 and the comment keep on being un-addressed.

The SoC either:
* has a clock that is required for the IP to work
* Or does not

It is not something you are free to provide or not.

For the record, I find very hard believe that some SoC would have clock,
and other would not, for the same HW.

Isn't it more likely that the clock just happens to be left enabled by
the bootloader on some SoC and it conviently allows to ignore it ?

> Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
> ---
>  drivers/crypto/amlogic/amlogic-gxl-core.c | 14 +++-----------
>  1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/crypto/amlogic/amlogic-gxl-core.c b/drivers/crypto/amlogic/amlogic-gxl-core.c
> index e9e733ed98e0..a3a69a59f476 100644
> --- a/drivers/crypto/amlogic/amlogic-gxl-core.c
> +++ b/drivers/crypto/amlogic/amlogic-gxl-core.c
> @@ -269,16 +269,11 @@ static int meson_crypto_probe(struct platform_device *pdev)
>  		dev_err(&pdev->dev, "Cannot request MMIO err=%d\n", err);
>  		return err;
>  	}
> -	mc->busclk = devm_clk_get(&pdev->dev, "blkmv");
> +
> +	mc->busclk = devm_clk_get_optional_enabled(&pdev->dev, "blkmv");
>  	if (IS_ERR(mc->busclk)) {
>  		err = PTR_ERR(mc->busclk);
> -		dev_err(&pdev->dev, "Cannot get core clock err=%d\n", err);
> -		return err;
> -	}
> -
> -	err = clk_prepare_enable(mc->busclk);
> -	if (err != 0) {
> -		dev_err(&pdev->dev, "Cannot prepare_enable busclk\n");
> +		dev_err(&pdev->dev, "Cannot get and enable core clock err=%d\n", err);
>  		return err;
>  	}
>  
> @@ -306,7 +301,6 @@ static int meson_crypto_probe(struct platform_device *pdev)
>  	meson_unregister_algs(mc);
>  error_flow:
>  	meson_free_chanlist(mc, mc->flow_cnt - 1);
> -	clk_disable_unprepare(mc->busclk);
>  	return err;
>  }
>  
> @@ -321,8 +315,6 @@ static void meson_crypto_remove(struct platform_device *pdev)
>  	meson_unregister_algs(mc);
>  
>  	meson_free_chanlist(mc, mc->flow_cnt - 1);
> -
> -	clk_disable_unprepare(mc->busclk);
>  }
>  
>  static const struct meson_pdata meson_gxl_pdata = {
Alexey Romanov March 4, 2024, 1:49 p.m. UTC | #2 
Hello Jerome,

On Fri, Mar 01, 2024 at 04:21:20PM +0100, Jerome Brunet wrote:
> 
> On Fri 01 Mar 2024 at 16:29, Alexey Romanov <avromanov@salutedevices.com> wrote:
> 
> > Amlogic crypto IP doesn't take a clock input on some
> > SoCs: AXG / A1 / S4 / G12. So make it optional.
> >
> 
> I commented this patch on v2 and the comment keep on being un-addressed.
> 
> The SoC either:
> * has a clock that is required for the IP to work
> * Or does not
> 
> It is not something you are free to provide or not.
> 
> For the record, I find very hard believe that some SoC would have clock,
> and other would not, for the same HW.
> 
> Isn't it more likely that the clock just happens to be left enabled by
> the bootloader on some SoC and it conviently allows to ignore it ?


S905X and newer SoC's uses DMA engine for crypto HW and they
don't required clock input to work. Clock input is needed for
blkmv engine.

Therefore, I'm not sure that it is needed for GXL too (and the second
interrupt line). I tested it on vim1 board witouht them and everything
works correctly.

> 
> > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
> > ---
> >  drivers/crypto/amlogic/amlogic-gxl-core.c | 14 +++-----------
> >  1 file changed, 3 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/crypto/amlogic/amlogic-gxl-core.c b/drivers/crypto/amlogic/amlogic-gxl-core.c
> > index e9e733ed98e0..a3a69a59f476 100644
> > --- a/drivers/crypto/amlogic/amlogic-gxl-core.c
> > +++ b/drivers/crypto/amlogic/amlogic-gxl-core.c
> > @@ -269,16 +269,11 @@ static int meson_crypto_probe(struct platform_device *pdev)
> >  		dev_err(&pdev->dev, "Cannot request MMIO err=%d\n", err);
> >  		return err;
> >  	}
> > -	mc->busclk = devm_clk_get(&pdev->dev, "blkmv");
> > +
> > +	mc->busclk = devm_clk_get_optional_enabled(&pdev->dev, "blkmv");
> >  	if (IS_ERR(mc->busclk)) {
> >  		err = PTR_ERR(mc->busclk);
> > -		dev_err(&pdev->dev, "Cannot get core clock err=%d\n", err);
> > -		return err;
> > -	}
> > -
> > -	err = clk_prepare_enable(mc->busclk);
> > -	if (err != 0) {
> > -		dev_err(&pdev->dev, "Cannot prepare_enable busclk\n");
> > +		dev_err(&pdev->dev, "Cannot get and enable core clock err=%d\n", err);
> >  		return err;
> >  	}
> >  
> > @@ -306,7 +301,6 @@ static int meson_crypto_probe(struct platform_device *pdev)
> >  	meson_unregister_algs(mc);
> >  error_flow:
> >  	meson_free_chanlist(mc, mc->flow_cnt - 1);
> > -	clk_disable_unprepare(mc->busclk);
> >  	return err;
> >  }
> >  
> > @@ -321,8 +315,6 @@ static void meson_crypto_remove(struct platform_device *pdev)
> >  	meson_unregister_algs(mc);
> >  
> >  	meson_free_chanlist(mc, mc->flow_cnt - 1);
> > -
> > -	clk_disable_unprepare(mc->busclk);
> >  }
> >  
> >  static const struct meson_pdata meson_gxl_pdata = {
> 
> 
> -- 
> Jerome
Alexey Romanov March 5, 2024, 1:47 p.m. UTC | #3 
On Mon, Mar 04, 2024 at 01:49:46PM +0000, Alexey Romanov wrote:
> Hello Jerome,
> 
> On Fri, Mar 01, 2024 at 04:21:20PM +0100, Jerome Brunet wrote:
> > 
> > On Fri 01 Mar 2024 at 16:29, Alexey Romanov <avromanov@salutedevices.com> wrote:
> > 
> > > Amlogic crypto IP doesn't take a clock input on some
> > > SoCs: AXG / A1 / S4 / G12. So make it optional.
> > >
> > 
> > I commented this patch on v2 and the comment keep on being un-addressed.
> > 
> > The SoC either:
> > * has a clock that is required for the IP to work
> > * Or does not
> > 
> > It is not something you are free to provide or not.
> > 
> > For the record, I find very hard believe that some SoC would have clock,
> > and other would not, for the same HW.
> > 
> > Isn't it more likely that the clock just happens to be left enabled by
> > the bootloader on some SoC and it conviently allows to ignore it ?
> 
> 
> S905X and newer SoC's uses DMA engine for crypto HW and they
> don't required clock input to work. Clock input is needed for
> blkmv engine.
> 
> Therefore, I'm not sure that it is needed for GXL too (and the second
> interrupt line). I tested it on vim1 board witouht them and everything
> works correctly.

Amlogic says that the crypto HW based on DMA engine doesn't require
a clock input. GXL uses DMA engine, so, I think we have to remove
whole clock controller calls in the next series from driver/dts/bindings.
And the second interrupt line from crypto node in meson-gxl.dtsi too.

> 
> > 
> > > Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
> > > ---
> > >  drivers/crypto/amlogic/amlogic-gxl-core.c | 14 +++-----------
> > >  1 file changed, 3 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/crypto/amlogic/amlogic-gxl-core.c b/drivers/crypto/amlogic/amlogic-gxl-core.c
> > > index e9e733ed98e0..a3a69a59f476 100644
> > > --- a/drivers/crypto/amlogic/amlogic-gxl-core.c
> > > +++ b/drivers/crypto/amlogic/amlogic-gxl-core.c
> > > @@ -269,16 +269,11 @@ static int meson_crypto_probe(struct platform_device *pdev)
> > >  		dev_err(&pdev->dev, "Cannot request MMIO err=%d\n", err);
> > >  		return err;
> > >  	}
> > > -	mc->busclk = devm_clk_get(&pdev->dev, "blkmv");
> > > +
> > > +	mc->busclk = devm_clk_get_optional_enabled(&pdev->dev, "blkmv");
> > >  	if (IS_ERR(mc->busclk)) {
> > >  		err = PTR_ERR(mc->busclk);
> > > -		dev_err(&pdev->dev, "Cannot get core clock err=%d\n", err);
> > > -		return err;
> > > -	}
> > > -
> > > -	err = clk_prepare_enable(mc->busclk);
> > > -	if (err != 0) {
> > > -		dev_err(&pdev->dev, "Cannot prepare_enable busclk\n");
> > > +		dev_err(&pdev->dev, "Cannot get and enable core clock err=%d\n", err);
> > >  		return err;
> > >  	}
> > >  
> > > @@ -306,7 +301,6 @@ static int meson_crypto_probe(struct platform_device *pdev)
> > >  	meson_unregister_algs(mc);
> > >  error_flow:
> > >  	meson_free_chanlist(mc, mc->flow_cnt - 1);
> > > -	clk_disable_unprepare(mc->busclk);
> > >  	return err;
> > >  }
> > >  
> > > @@ -321,8 +315,6 @@ static void meson_crypto_remove(struct platform_device *pdev)
> > >  	meson_unregister_algs(mc);
> > >  
> > >  	meson_free_chanlist(mc, mc->flow_cnt - 1);
> > > -
> > > -	clk_disable_unprepare(mc->busclk);
> > >  }
> > >  
> > >  static const struct meson_pdata meson_gxl_pdata = {
> > 
> > 
> > -- 
> > Jerome
> 
> -- 
> Thank you,
> Alexey
Corentin Labbe March 22, 2024, 8:27 a.m. UTC | #4 
Le Fri, Mar 01, 2024 at 04:29:24PM +0300, Alexey Romanov a écrit :
> 1. The old alhorithm was not designed to process a large
> amount of memory, and therefore gave incorrect results.
> 
> 2. Not all Amlogic SoC's use 3 KEY/IV descriptors.
> Add keyiv descriptors count parameter to platform data.
> 
> Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
> ---
>  drivers/crypto/amlogic/amlogic-gxl-cipher.c | 441 ++++++++++++--------
>  drivers/crypto/amlogic/amlogic-gxl-core.c   |   1 +
>  drivers/crypto/amlogic/amlogic-gxl.h        |   2 +
>  3 files changed, 280 insertions(+), 164 deletions(-)
> 

Hello

I have started to test by adding patch one by one and when testing this one I got:
[   21.674995] gxl-crypto c883e000.crypto: will run requests pump with realtime priority
[   21.679686] gxl-crypto c883e000.crypto: will run requests pump with realtime priority
[   21.704366] ------------[ cut here ]------------
[   21.704480] DMA-API: gxl-crypto c883e000.crypto: device driver tries to sync DMA memory it has not allocated [device address=0x000000000264c000] [size=48 bytes]
[   21.717684] WARNING: CPU: 1 PID: 263 at kernel/dma/debug.c:1105 check_sync+0x1d0/0x688
[   21.725512] Modules linked in: meson_rng meson_gxbb_wdt rng_core amlogic_gxl_crypto(+) meson_canvas libphy(+) watchdog ghash_generic gcm xctr xts cts essiv authenc cmac xcbc ccm
[   21.741211] CPU: 1 PID: 263 Comm: c883e000.crypto Not tainted 6.8.0-rc1-00052-g595d4248b127 #24
[   21.749834] Hardware name: Libre Computer AML-S905X-CC (DT)
[   21.755353] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   21.762252] pc : check_sync+0x1d0/0x688
[   21.766047] lr : check_sync+0x1d0/0x688
[   21.769842] sp : ffff8000820fbb40
[   21.773119] x29: ffff8000820fbb40 x28: 0000000000000000 x27: 0000000000000000
[   21.780192] x26: ffff800081d639d0 x25: 0000000000001327 x24: ffff00000288b010
[   21.787265] x23: 0000000000000050 x22: 0000000000001327 x21: ffff800081c23a20
[   21.794336] x20: ffff800080fe0bb8 x19: ffff8000820fbbc0 x18: 0000000000000006
[   21.801410] x17: 645b206465746163 x16: 6f6c6c6120746f6e x15: ffff8000820fb540
[   21.808482] x14: 000000000000000b x13: ffff800081002748 x12: 0000000000000249
[   21.815554] x11: 00000000000000c3 x10: ffff80008105a748 x9 : ffff800081002748
[   21.822626] x8 : 00000000ffffefff x7 : ffff80008105a748 x6 : 80000000fffff000
[   21.829700] x5 : ffff00007d9abb08 x4 : 0000000000000000 x3 : 0000000000000027
[   21.836772] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00000b314ec0
[   21.843844] Call trace:
[   21.846260]  check_sync+0x1d0/0x688
[   21.849710]  debug_dma_sync_single_for_device+0xb8/0xc0
[   21.854885]  dma_sync_single_for_device+0xc0/0x11c
[   21.859628]  meson_handle_cipher_request+0x49c/0x7c4 [amlogic_gxl_crypto]
[   21.866356]  crypto_pump_work+0x160/0x2ac
[   21.870324]  kthread_worker_fn+0xe4/0x300
[   21.874291]  kthread+0x11c/0x120
[   21.877483]  ret_from_fork+0x10/0x20
[   21.881020] irq event stamp: 9880
[   21.884296] hardirqs last  enabled at (9879): [<ffff800080988834>] _raw_spin_unlock_irqrestore+0x6c/0x70
[   21.893698] hardirqs last disabled at (9880): [<ffff800080987ca0>] _raw_spin_lock_irqsave+0x84/0x88
[   21.902668] softirqs last  enabled at (5638): [<ffff800080010674>] __do_softirq+0x494/0x4dc
[   21.910947] softirqs last disabled at (5627): [<ffff8000800161f0>] ____do_softirq+0x10/0x1c
[   21.919227] ---[ end trace 0000000000000000 ]---

Regards
Neil Armstrong March 22, 2024, 10:14 a.m. UTC | #5 
On 22/03/2024 09:27, Corentin Labbe wrote:
> Le Fri, Mar 01, 2024 at 04:29:24PM +0300, Alexey Romanov a écrit :
>> 1. The old alhorithm was not designed to process a large
>> amount of memory, and therefore gave incorrect results.
>>
>> 2. Not all Amlogic SoC's use 3 KEY/IV descriptors.
>> Add keyiv descriptors count parameter to platform data.
>>
>> Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
>> ---
>>   drivers/crypto/amlogic/amlogic-gxl-cipher.c | 441 ++++++++++++--------
>>   drivers/crypto/amlogic/amlogic-gxl-core.c   |   1 +
>>   drivers/crypto/amlogic/amlogic-gxl.h        |   2 +
>>   3 files changed, 280 insertions(+), 164 deletions(-)
>>
> 
> Hello
> 
> I have started to test by adding patch one by one and when testing this one I got:
> [   21.674995] gxl-crypto c883e000.crypto: will run requests pump with realtime priority
> [   21.679686] gxl-crypto c883e000.crypto: will run requests pump with realtime priority
> [   21.704366] ------------[ cut here ]------------
> [   21.704480] DMA-API: gxl-crypto c883e000.crypto: device driver tries to sync DMA memory it has not allocated [device address=0x000000000264c000] [size=48 bytes]
> [   21.717684] WARNING: CPU: 1 PID: 263 at kernel/dma/debug.c:1105 check_sync+0x1d0/0x688
> [   21.725512] Modules linked in: meson_rng meson_gxbb_wdt rng_core amlogic_gxl_crypto(+) meson_canvas libphy(+) watchdog ghash_generic gcm xctr xts cts essiv authenc cmac xcbc ccm
> [   21.741211] CPU: 1 PID: 263 Comm: c883e000.crypto Not tainted 6.8.0-rc1-00052-g595d4248b127 #24
> [   21.749834] Hardware name: Libre Computer AML-S905X-CC (DT)
> [   21.755353] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [   21.762252] pc : check_sync+0x1d0/0x688
> [   21.766047] lr : check_sync+0x1d0/0x688
> [   21.769842] sp : ffff8000820fbb40
> [   21.773119] x29: ffff8000820fbb40 x28: 0000000000000000 x27: 0000000000000000
> [   21.780192] x26: ffff800081d639d0 x25: 0000000000001327 x24: ffff00000288b010
> [   21.787265] x23: 0000000000000050 x22: 0000000000001327 x21: ffff800081c23a20
> [   21.794336] x20: ffff800080fe0bb8 x19: ffff8000820fbbc0 x18: 0000000000000006
> [   21.801410] x17: 645b206465746163 x16: 6f6c6c6120746f6e x15: ffff8000820fb540
> [   21.808482] x14: 000000000000000b x13: ffff800081002748 x12: 0000000000000249
> [   21.815554] x11: 00000000000000c3 x10: ffff80008105a748 x9 : ffff800081002748
> [   21.822626] x8 : 00000000ffffefff x7 : ffff80008105a748 x6 : 80000000fffff000
> [   21.829700] x5 : ffff00007d9abb08 x4 : 0000000000000000 x3 : 0000000000000027
> [   21.836772] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00000b314ec0
> [   21.843844] Call trace:
> [   21.846260]  check_sync+0x1d0/0x688
> [   21.849710]  debug_dma_sync_single_for_device+0xb8/0xc0
> [   21.854885]  dma_sync_single_for_device+0xc0/0x11c
> [   21.859628]  meson_handle_cipher_request+0x49c/0x7c4 [amlogic_gxl_crypto]
> [   21.866356]  crypto_pump_work+0x160/0x2ac
> [   21.870324]  kthread_worker_fn+0xe4/0x300
> [   21.874291]  kthread+0x11c/0x120
> [   21.877483]  ret_from_fork+0x10/0x20
> [   21.881020] irq event stamp: 9880
> [   21.884296] hardirqs last  enabled at (9879): [<ffff800080988834>] _raw_spin_unlock_irqrestore+0x6c/0x70
> [   21.893698] hardirqs last disabled at (9880): [<ffff800080987ca0>] _raw_spin_lock_irqsave+0x84/0x88
> [   21.902668] softirqs last  enabled at (5638): [<ffff800080010674>] __do_softirq+0x494/0x4dc
> [   21.910947] softirqs last disabled at (5627): [<ffff8000800161f0>] ____do_softirq+0x10/0x1c
> [   21.919227] ---[ end trace 0000000000000000 ]---

I confirm I see the same starting with this change with DMA_API_DEBUG=1

[    4.745240] ------------[ cut here ]------------
[    4.745295] DMA-API: gxl-crypto c883e000.crypto: device driver tries to sync DMA memory it has not allocated [device address=0x000000000a816030] [size=16 bytes]
[    4.758496] WARNING: CPU: 3 PID: 75 at kernel/dma/debug.c:1105 check_sync+0x1d8/0x690
[    4.766242] Modules linked in:
[    4.769258] CPU: 3 PID: 75 Comm: c883e000.crypto Not tainted 6.8.0-rc6-next-20240229-g99fbe5828431 #167
[    4.778576] Hardware name: Libre Computer AML-S905X-CC (DT)
[    4.784094] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    4.790993] pc : check_sync+0x1d8/0x690
[    4.794786] lr : check_sync+0x1d8/0x690
[    4.798581] sp : ffff800082563b90
[    4.801859] x29: ffff800082563b90 x28: ffff8000816ef298 x27: 0000000000000000
[    4.808934] x26: ffff0000041ed010 x25: 0000000000000018 x24: 0000000000004000
[    4.816006] x23: ffff8000816d1190 x22: 0000000000004000 x21: ffff800081539b50
[    4.823079] x20: ffff800082563c40 x19: ffff8000816ef2b0 x18: 0000000000000030
[    4.830151] x17: 645b206465746163 x16: 6f6c6c6120746f6e x15: 0720072007200720
[    4.837223] x14: ffff80008154f2c0 x13: 00000000000002a6 x12: 00000000000000e2
[    4.844296] x11: 0720072007200720 x10: ffff8000815a72c0 x9 : 00000000fffff000
[    4.851369] x8 : ffff80008154f2c0 x7 : ffff8000815a72c0 x6 : 0000000000000000
[    4.858441] x5 : 80000000fffff000 x4 : 000000000000aff5 x3 : 0000000000000000
[    4.865514] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000091a9100
[    4.872587] Call trace:
[    4.874999]  check_sync+0x1d8/0x690
[    4.878449]  debug_dma_sync_single_for_cpu+0x84/0x8c
[    4.883366]  dma_sync_single_for_cpu+0x58/0x10c
[    4.887851]  meson_handle_cipher_request+0x3b0/0x780
[    4.892767]  crypto_pump_work+0x15c/0x2bc
[    4.896734]  kthread_worker_fn+0xcc/0x184
[    4.900702]  kthread+0x118/0x11c
[    4.903893]  ret_from_fork+0x10/0x20
[    4.907430] ---[ end trace 0000000000000000 ]---

Thanks,
Neil

> 
> Regards