mbox series

[v2,00/17] Enable Qualcomm Crypto Engine on sm8250

Message ID 20210505213731.538612-1-bhupesh.sharma@linaro.org
Headers show
Series Enable Qualcomm Crypto Engine on sm8250 | expand

Message

Bhupesh Sharma May 5, 2021, 9:37 p.m. UTC 
Changes since v1:
=================
- v1 can be seen here: https://lore.kernel.org/linux-arm-msm/20210310052503.3618486-1-bhupesh.sharma@linaro.org/ 
- v1 did not work well as reported earlier by Dmitry, so v2 contains the following
  changes/fixes:
  ~ Enable the interconnect path b/w BAM DMA and main memory first
    before trying to access the BAM DMA registers.
  ~ Enable the interconnect path b/w qce crytpo and main memory first
    before trying to access the qce crypto registers.
  ~ Make sure to document the required and optional properties for both
    BAM DMA and qce crypto drivers.
  ~ Add a few debug related print messages in case the qce crypto driver
    passes or fails to probe.
  ~ Convert the qce crypto driver probe to a defered one in case the BAM DMA
    or the interconnect driver(s) (needed on specific Qualcomm parts) are not
    yet probed.

Qualcomm crypto engine is also available on sm8250 SoC.
It supports hardware accelerated algorithms for encryption
and authentication. It also provides support for aes, des, 3des
encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
authentication algorithms.

Tested the enabled crypto algorithms with cryptsetup test utilities
on sm8250-mtp and RB5 board (see [1]).

While at it, also make a minor fix in 'sdm845.dtsi', to make
sure it confirms with the other .dtsi files which expose
crypto nodes on qcom SoCs.

Cc: Thara Gopinath <thara.gopinath@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: dmaengine@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: bhupesh.linux@gmail.com
 
Bhupesh Sharma (14):
  dt-bindings: qcom-bam: Add 'interconnects' & 'interconnect-names' to
    optional properties
  dt-bindings: qcom-bam: Add 'iommus' to required properties
  dt-bindings: qcom-qce: Add 'iommus' to required properties
  dt-bindings: qcom-qce: Add 'interconnects' and move 'clocks' to
    optional properties
  arm64/dts: qcom: sdm845: Use RPMH_CE_CLK macro directly
  dt-bindings: crypto : Add new compatible strings for qcom-qce
  arm64/dts: qcom: Use new compatibles for crypto nodes
  crypto: qce: Add new compatibles for qce crypto driver
  crypto: qce: Print a failure msg in case probe() fails
  crypto: qce: Convert the device found dev_dbg() to dev_info()
  dma: qcom: bam_dma: Create a new header file for BAM DMA driver
  crypto: qce: Defer probing if BAM dma is not yet initialized
  crypto: qce: Defer probe in case interconnect is not yet initialized
  arm64/dts: qcom: sm8250: Add dt entries to support crypto engine.

Thara Gopinath (3):
  dma: qcom: bam_dma: Add support to initialize interconnect path
  crypto: qce: core: Add support to initialize interconnect path
  crypto: qce: core: Make clocks optional

 .../devicetree/bindings/crypto/qcom-qce.txt   |  22 +-
 .../devicetree/bindings/dma/qcom_bam_dma.txt  |   5 +
 arch/arm64/boot/dts/qcom/ipq6018.dtsi         |   2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi          |   6 +-
 arch/arm64/boot/dts/qcom/sm8250.dtsi          |  28 ++
 drivers/crypto/qce/core.c                     | 112 +++++--
 drivers/crypto/qce/core.h                     |   3 +
 drivers/dma/qcom/bam_dma.c                    | 306 ++----------------
 include/soc/qcom/bam_dma.h                    | 290 +++++++++++++++++
 9 files changed, 457 insertions(+), 317 deletions(-)
 create mode 100644 include/soc/qcom/bam_dma.h

Comments

Eric Biggers May 5, 2021, 10:09 p.m. UTC | #1 
On Thu, May 06, 2021 at 03:07:14AM +0530, Bhupesh Sharma wrote:
> 
> Tested the enabled crypto algorithms with cryptsetup test utilities
> on sm8250-mtp and RB5 board (see [1]).
> 

Does this driver also pass the crypto self-tests, including the fuzz tests
(CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y)?

- Eric
Bhupesh Sharma May 7, 2021, 9:12 p.m. UTC | #2 
Hello Eric,

On Thu, 6 May 2021 at 03:39, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Thu, May 06, 2021 at 03:07:14AM +0530, Bhupesh Sharma wrote:
> >
> > Tested the enabled crypto algorithms with cryptsetup test utilities
> > on sm8250-mtp and RB5 board (see [1]).
> >
>
> Does this driver also pass the crypto self-tests, including the fuzz tests
> (CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y)?

I did try running these self-tests and they pass with
'CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y' as well. Do note that we need
the AEAD fixes from Thara (see[1]) for all of the fuzz tests to work
(so my patches are actually rebased on this series).

[1]. https://lore.kernel.org/linux-crypto/20210429150707.3168383-5-thara.gopinath@linaro.org/T/

Thanks,
Bhupesh
Rob Herring (Arm) May 7, 2021, 9:14 p.m. UTC | #3 
On Thu, May 06, 2021 at 03:07:14AM +0530, Bhupesh Sharma wrote:
> Changes since v1:
> =================
> - v1 can be seen here: https://lore.kernel.org/linux-arm-msm/20210310052503.3618486-1-bhupesh.sharma@linaro.org/ 
> - v1 did not work well as reported earlier by Dmitry, so v2 contains the following
>   changes/fixes:
>   ~ Enable the interconnect path b/w BAM DMA and main memory first
>     before trying to access the BAM DMA registers.
>   ~ Enable the interconnect path b/w qce crytpo and main memory first
>     before trying to access the qce crypto registers.
>   ~ Make sure to document the required and optional properties for both
>     BAM DMA and qce crypto drivers.
>   ~ Add a few debug related print messages in case the qce crypto driver
>     passes or fails to probe.
>   ~ Convert the qce crypto driver probe to a defered one in case the BAM DMA
>     or the interconnect driver(s) (needed on specific Qualcomm parts) are not
>     yet probed.
> 
> Qualcomm crypto engine is also available on sm8250 SoC.
> It supports hardware accelerated algorithms for encryption
> and authentication. It also provides support for aes, des, 3des
> encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
> authentication algorithms.
> 
> Tested the enabled crypto algorithms with cryptsetup test utilities
> on sm8250-mtp and RB5 board (see [1]).
> 
> While at it, also make a minor fix in 'sdm845.dtsi', to make
> sure it confirms with the other .dtsi files which expose
> crypto nodes on qcom SoCs.
> 
> Cc: Thara Gopinath <thara.gopinath@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: bhupesh.linux@gmail.com
>  
> Bhupesh Sharma (14):
>   dt-bindings: qcom-bam: Add 'interconnects' & 'interconnect-names' to
>     optional properties
>   dt-bindings: qcom-bam: Add 'iommus' to required properties
>   dt-bindings: qcom-qce: Add 'iommus' to required properties
>   dt-bindings: qcom-qce: Add 'interconnects' and move 'clocks' to
>     optional properties
>   arm64/dts: qcom: sdm845: Use RPMH_CE_CLK macro directly
>   dt-bindings: crypto : Add new compatible strings for qcom-qce

Please convert these bindings to schemas.


>   arm64/dts: qcom: Use new compatibles for crypto nodes
>   crypto: qce: Add new compatibles for qce crypto driver
>   crypto: qce: Print a failure msg in case probe() fails
>   crypto: qce: Convert the device found dev_dbg() to dev_info()
>   dma: qcom: bam_dma: Create a new header file for BAM DMA driver
>   crypto: qce: Defer probing if BAM dma is not yet initialized
>   crypto: qce: Defer probe in case interconnect is not yet initialized
>   arm64/dts: qcom: sm8250: Add dt entries to support crypto engine.
> 
> Thara Gopinath (3):
>   dma: qcom: bam_dma: Add support to initialize interconnect path
>   crypto: qce: core: Add support to initialize interconnect path
>   crypto: qce: core: Make clocks optional
> 
>  .../devicetree/bindings/crypto/qcom-qce.txt   |  22 +-
>  .../devicetree/bindings/dma/qcom_bam_dma.txt  |   5 +
>  arch/arm64/boot/dts/qcom/ipq6018.dtsi         |   2 +-
>  arch/arm64/boot/dts/qcom/sdm845.dtsi          |   6 +-
>  arch/arm64/boot/dts/qcom/sm8250.dtsi          |  28 ++
>  drivers/crypto/qce/core.c                     | 112 +++++--
>  drivers/crypto/qce/core.h                     |   3 +
>  drivers/dma/qcom/bam_dma.c                    | 306 ++----------------
>  include/soc/qcom/bam_dma.h                    | 290 +++++++++++++++++
>  9 files changed, 457 insertions(+), 317 deletions(-)
>  create mode 100644 include/soc/qcom/bam_dma.h
> 
> -- 
> 2.30.2
>
Bhupesh Sharma May 8, 2021, 6:56 p.m. UTC | #4 
Hi Rob,

On Sat, 8 May 2021 at 02:44, Rob Herring <robh@kernel.org> wrote:
>
> On Thu, May 06, 2021 at 03:07:14AM +0530, Bhupesh Sharma wrote:
> > Changes since v1:
> > =================
> > - v1 can be seen here: https://lore.kernel.org/linux-arm-msm/20210310052503.3618486-1-bhupesh.sharma@linaro.org/
> > - v1 did not work well as reported earlier by Dmitry, so v2 contains the following
> >   changes/fixes:
> >   ~ Enable the interconnect path b/w BAM DMA and main memory first
> >     before trying to access the BAM DMA registers.
> >   ~ Enable the interconnect path b/w qce crytpo and main memory first
> >     before trying to access the qce crypto registers.
> >   ~ Make sure to document the required and optional properties for both
> >     BAM DMA and qce crypto drivers.
> >   ~ Add a few debug related print messages in case the qce crypto driver
> >     passes or fails to probe.
> >   ~ Convert the qce crypto driver probe to a defered one in case the BAM DMA
> >     or the interconnect driver(s) (needed on specific Qualcomm parts) are not
> >     yet probed.
> >
> > Qualcomm crypto engine is also available on sm8250 SoC.
> > It supports hardware accelerated algorithms for encryption
> > and authentication. It also provides support for aes, des, 3des
> > encryption algorithms and sha1, sha256, hmac(sha1), hmac(sha256)
> > authentication algorithms.
> >
> > Tested the enabled crypto algorithms with cryptsetup test utilities
> > on sm8250-mtp and RB5 board (see [1]).
> >
> > While at it, also make a minor fix in 'sdm845.dtsi', to make
> > sure it confirms with the other .dtsi files which expose
> > crypto nodes on qcom SoCs.
> >
> > Cc: Thara Gopinath <thara.gopinath@linaro.org>
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Andy Gross <agross@kernel.org>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Cc: dmaengine@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-crypto@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: bhupesh.linux@gmail.com
> >
> > Bhupesh Sharma (14):
> >   dt-bindings: qcom-bam: Add 'interconnects' & 'interconnect-names' to
> >     optional properties
> >   dt-bindings: qcom-bam: Add 'iommus' to required properties
> >   dt-bindings: qcom-qce: Add 'iommus' to required properties
> >   dt-bindings: qcom-qce: Add 'interconnects' and move 'clocks' to
> >     optional properties
> >   arm64/dts: qcom: sdm845: Use RPMH_CE_CLK macro directly
> >   dt-bindings: crypto : Add new compatible strings for qcom-qce
>
> Please convert these bindings to schemas.

Ok, will fix it in v3.

Thanks,
Bhupesh

>
> >   arm64/dts: qcom: Use new compatibles for crypto nodes
> >   crypto: qce: Add new compatibles for qce crypto driver
> >   crypto: qce: Print a failure msg in case probe() fails
> >   crypto: qce: Convert the device found dev_dbg() to dev_info()
> >   dma: qcom: bam_dma: Create a new header file for BAM DMA driver
> >   crypto: qce: Defer probing if BAM dma is not yet initialized
> >   crypto: qce: Defer probe in case interconnect is not yet initialized
> >   arm64/dts: qcom: sm8250: Add dt entries to support crypto engine.
> >
> > Thara Gopinath (3):
> >   dma: qcom: bam_dma: Add support to initialize interconnect path
> >   crypto: qce: core: Add support to initialize interconnect path
> >   crypto: qce: core: Make clocks optional
> >
> >  .../devicetree/bindings/crypto/qcom-qce.txt   |  22 +-
> >  .../devicetree/bindings/dma/qcom_bam_dma.txt  |   5 +
> >  arch/arm64/boot/dts/qcom/ipq6018.dtsi         |   2 +-
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi          |   6 +-
> >  arch/arm64/boot/dts/qcom/sm8250.dtsi          |  28 ++
> >  drivers/crypto/qce/core.c                     | 112 +++++--
> >  drivers/crypto/qce/core.h                     |   3 +
> >  drivers/dma/qcom/bam_dma.c                    | 306 ++----------------
> >  include/soc/qcom/bam_dma.h                    | 290 +++++++++++++++++
> >  9 files changed, 457 insertions(+), 317 deletions(-)
> >  create mode 100644 include/soc/qcom/bam_dma.h
> >
> > --
> > 2.30.2
> >
Vinod Koul May 9, 2021, 1:58 p.m. UTC | #5 
On 06-05-21, 03:07, Bhupesh Sharma wrote:
> Create a new header file for BAM DMA driver to make sure
> that it can be included in the follow-up patch to defer probing
> drivers which require BAM DMA driver to be first probed successfully.
> 
> Cc: Thara Gopinath <thara.gopinath@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: bhupesh.linux@gmail.com
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> ---
>  drivers/dma/qcom/bam_dma.c | 283 +-----------------------------------
>  include/soc/qcom/bam_dma.h | 290 +++++++++++++++++++++++++++++++++++++

1. Please use -M with move patches...

2. susbsytem is dmaengine

3. Why move..? These things are internal to the driver and I dont think
it is wise for clients to use everything here... If the client needs to
know defer probe, it should request a channel and check the status
returned for EPROBE_DEFER

Thanks
Bhupesh Sharma May 9, 2021, 7:20 p.m. UTC | #6 
Hi Vinod,

Thanks for the review.

On Sun, 9 May 2021 at 19:28, Vinod Koul <vkoul@kernel.org> wrote:
>
> On 06-05-21, 03:07, Bhupesh Sharma wrote:
> > Create a new header file for BAM DMA driver to make sure
> > that it can be included in the follow-up patch to defer probing
> > drivers which require BAM DMA driver to be first probed successfully.
> >
> > Cc: Thara Gopinath <thara.gopinath@linaro.org>
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Andy Gross <agross@kernel.org>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Cc: dmaengine@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-crypto@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: bhupesh.linux@gmail.com
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> > ---
> >  drivers/dma/qcom/bam_dma.c | 283 +-----------------------------------
> >  include/soc/qcom/bam_dma.h | 290 +++++++++++++++++++++++++++++++++++++
>
> 1. Please use -M with move patches...

Oops, will do.

> 2. susbsytem is dmaengine
>
> 3. Why move..? These things are internal to the driver and I dont think
> it is wise for clients to use everything here... If the client needs to
> know defer probe, it should request a channel and check the status
> returned for EPROBE_DEFER

Yes, the main intent is to defer the probe of the calling client driver in
case the BAM DMA is not probed() yet.

Sure, I will make the suggested change in v3,

Regards,
Bhupesh
Thara Gopinath May 10, 2021, 1:22 p.m. UTC | #7 
On 5/5/21 5:37 PM, Bhupesh Sharma wrote:
> Since the Qualcomm qce crypto driver needs the BAM dma driver to be
> setup first (to allow crypto operations), it makes sense to defer
> the qce crypto driver probing in case the BAM dma driver is not yet
> probed.
> 
> This fixes the qce probe failure issues when both qce and BMA dma
> are compiled as static part of the kernel.
> 
> Cc: Thara Gopinath <thara.gopinath@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: bhupesh.linux@gmail.com
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> ---
>   drivers/crypto/qce/core.c  | 4 ++++
>   drivers/dma/qcom/bam_dma.c | 7 +++++++
>   2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> index 9a7d7ef94687..3e742e9911fa 100644
> --- a/drivers/crypto/qce/core.c
> +++ b/drivers/crypto/qce/core.c
> @@ -15,6 +15,7 @@
>   #include <linux/types.h>
>   #include <crypto/algapi.h>
>   #include <crypto/internal/hash.h>
> +#include <soc/qcom/bam_dma.h>
>   
>   #include "core.h"
>   #include "cipher.h"
> @@ -201,6 +202,9 @@ static int qce_crypto_probe(struct platform_device *pdev)
>   			of_match_device(qce_crypto_of_match, &pdev->dev);
>   	int ret;
>   
> +	/* qce driver requires BAM dma driver to be setup first */
> +	if (!bam_is_probed())
> +		return -EPROBE_DEFER;

Hi Bhupesh,

You don't need this here. qce_dma_request returns -EPROBE_DEFER if the 
dma controller is not probed yet.
Thara Gopinath May 10, 2021, 1:23 p.m. UTC | #8 
On 5/5/21 5:37 PM, Bhupesh Sharma wrote:
> On some Qualcomm parts the qce crypto driver needs the interconnect between
> the crypto block and main memory to be initialized first before the crypto
> registers can be accessed. So it makes sense to defer the qce crypto driver
> probing in case the interconnect driver is not yet probed.
> 
> This fixes the qce probe failure issues when both qce and
> interconnect drivers are compiled as static part of the kernel.
> 
> Cc: Thara Gopinath <thara.gopinath@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: bhupesh.linux@gmail.com
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> ---
>   drivers/crypto/qce/core.c | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> index 3e742e9911fa..9915b184f780 100644
> --- a/drivers/crypto/qce/core.c
> +++ b/drivers/crypto/qce/core.c
> @@ -222,6 +222,20 @@ static int qce_crypto_probe(struct platform_device *pdev)
>   		return ret;
>   
>   	qce->mem_path = of_icc_get(qce->dev, "memory");
> +
> +	/* Check for NULL return path, which indicates
> +	 * interconnect API is disabled or the "interconnects"
> +	 * DT property is missing.
> +	 */
> +	if (!qce->mem_path)
> +		/* On some qcom parts, the qce crypto block needs interconnect
> +		 * paths to be configured before the registers can be accessed.
> +		 * Check here for the same.
> +		 */
> +		if (!strcmp(of_id->compatible, "qcom,ipq6018-qce") ||
> +		    !strcmp(of_id->compatible, "qcom,sdm845-qce"))
> +			return -EPROBE_DEFER;
> +

Hi Bhupesh,

You don't need this here. of_icc_get returns -EPROBE_DEFER if the 
interconnect provider is not initialized yet.
Rafael Reinoldes May 10, 2021, 1:58 p.m. UTC | #9 
unsubscribe
Bhupesh Sharma May 18, 2021, 2:39 p.m. UTC | #10 
Hi Thara,

On Mon, 10 May 2021 at 18:53, Thara Gopinath <thara.gopinath@linaro.org> wrote:
>
>
>
> On 5/5/21 5:37 PM, Bhupesh Sharma wrote:
> > On some Qualcomm parts the qce crypto driver needs the interconnect between
> > the crypto block and main memory to be initialized first before the crypto
> > registers can be accessed. So it makes sense to defer the qce crypto driver
> > probing in case the interconnect driver is not yet probed.
> >
> > This fixes the qce probe failure issues when both qce and
> > interconnect drivers are compiled as static part of the kernel.
> >
> > Cc: Thara Gopinath <thara.gopinath@linaro.org>
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Andy Gross <agross@kernel.org>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Cc: dmaengine@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-crypto@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: bhupesh.linux@gmail.com
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> > ---
> >   drivers/crypto/qce/core.c | 14 ++++++++++++++
> >   1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> > index 3e742e9911fa..9915b184f780 100644
> > --- a/drivers/crypto/qce/core.c
> > +++ b/drivers/crypto/qce/core.c
> > @@ -222,6 +222,20 @@ static int qce_crypto_probe(struct platform_device *pdev)
> >               return ret;
> >
> >       qce->mem_path = of_icc_get(qce->dev, "memory");
> > +
> > +     /* Check for NULL return path, which indicates
> > +      * interconnect API is disabled or the "interconnects"
> > +      * DT property is missing.
> > +      */
> > +     if (!qce->mem_path)
> > +             /* On some qcom parts, the qce crypto block needs interconnect
> > +              * paths to be configured before the registers can be accessed.
> > +              * Check here for the same.
> > +              */
> > +             if (!strcmp(of_id->compatible, "qcom,ipq6018-qce") ||
> > +                 !strcmp(of_id->compatible, "qcom,sdm845-qce"))
> > +                     return -EPROBE_DEFER;
> > +
>
> Hi Bhupesh,
>
> You don't need this here. of_icc_get returns -EPROBE_DEFER if the
> interconnect provider is not initialized yet.

Thanks for the review.

Yes, I finished testing all the possible combinations with qce, bam
dma and interconnect drivers compiled as modules v/s as static parts
of the kernel and we don't need this extra check for the interconnect
here. We should be fine with checking just the qce_dma_request()
return value and returning early in the qce probe() flow if no dma
channels are yet available from the bam dma driver.

I have made the changes in v3 and will post it for review shortly.

Regards,
Bhupesh
Bhupesh Sharma May 18, 2021, 2:44 p.m. UTC | #11 
HI Thara,

On Mon, 10 May 2021 at 18:52, Thara Gopinath <thara.gopinath@linaro.org> wrote:
>
>
>
> On 5/5/21 5:37 PM, Bhupesh Sharma wrote:
> > Since the Qualcomm qce crypto driver needs the BAM dma driver to be
> > setup first (to allow crypto operations), it makes sense to defer
> > the qce crypto driver probing in case the BAM dma driver is not yet
> > probed.
> >
> > This fixes the qce probe failure issues when both qce and BMA dma
> > are compiled as static part of the kernel.
> >
> > Cc: Thara Gopinath <thara.gopinath@linaro.org>
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Andy Gross <agross@kernel.org>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Cc: dmaengine@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-crypto@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: bhupesh.linux@gmail.com
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> > ---
> >   drivers/crypto/qce/core.c  | 4 ++++
> >   drivers/dma/qcom/bam_dma.c | 7 +++++++
> >   2 files changed, 11 insertions(+)
> >
> > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> > index 9a7d7ef94687..3e742e9911fa 100644
> > --- a/drivers/crypto/qce/core.c
> > +++ b/drivers/crypto/qce/core.c
> > @@ -15,6 +15,7 @@
> >   #include <linux/types.h>
> >   #include <crypto/algapi.h>
> >   #include <crypto/internal/hash.h>
> > +#include <soc/qcom/bam_dma.h>
> >
> >   #include "core.h"
> >   #include "cipher.h"
> > @@ -201,6 +202,9 @@ static int qce_crypto_probe(struct platform_device *pdev)
> >                       of_match_device(qce_crypto_of_match, &pdev->dev);
> >       int ret;
> >
> > +     /* qce driver requires BAM dma driver to be setup first */
> > +     if (!bam_is_probed())
> > +             return -EPROBE_DEFER;
>
> Hi Bhupesh,
>
> You don't need this here. qce_dma_request returns -EPROBE_DEFER if the
> dma controller is not probed yet.

Thanks for the review.

Yes, we can just use qce_dma_request() return value to return from the
qce probe() function early, in case the bam dma channels are not
available yet.

I have made the changes in v3 and will post it for review shortly.

Regards,
Bhupesh






> >
> >       qce = devm_kzalloc(dev, sizeof(*qce), GFP_KERNEL);
> >       if (!qce)
> > diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> > index 2bc3b7c7ee5a..c854fcc82dbf 100644
> > --- a/drivers/dma/qcom/bam_dma.c
> > +++ b/drivers/dma/qcom/bam_dma.c
> > @@ -935,6 +935,12 @@ static void bam_channel_init(struct bam_device *bdev, struct bam_chan *bchan,
> >       INIT_LIST_HEAD(&bchan->desc_list);
> >   }
> >
> > +bool bam_is_probed(void)
> > +{
> > +     return bam_probed;
> > +}
> > +EXPORT_SYMBOL_GPL(bam_is_probed);
> > +
> >   static const struct of_device_id bam_of_match[] = {
> >       { .compatible = "qcom,bam-v1.3.0", .data = &bam_v1_3_reg_info },
> >       { .compatible = "qcom,bam-v1.4.0", .data = &bam_v1_4_reg_info },
> > @@ -1084,6 +1090,7 @@ static int bam_dma_probe(struct platform_device *pdev)
> >       if (ret)
> >               goto err_unregister_dma;
> >
> > +     bam_probed = true;
> >       if (!bdev->bamclk) {
> >               pm_runtime_disable(&pdev->dev);
> >               return 0;
> >
>
Bjorn Andersson May 18, 2021, 3:07 p.m. UTC | #12 
On Wed 05 May 16:37 CDT 2021, Bhupesh Sharma wrote:

> From: Thara Gopinath <thara.gopinath@linaro.org>
> 
> Crypto engine on certain Snapdragon processors like sm8150, sm8250, sm8350
> etc. requires interconnect path between the engine and memory to be
> explicitly enabled and bandwidth set prior to any operations. Add support
> in the qce core to enable the interconnect path appropriately.
> 
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Vinod Koul <vkoul@kernel.org>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: bhupesh.linux@gmail.com
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> [Make header file inclusion alphabetical]
> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>

This says that you prepared the patch, then Thara picked up the patch
and sorted the includes. But somehow you then sent the patch.

I.e. you name should be the last - unless you jointly wrote the path, in
which case you should also add a "Co-developed-by: Thara".

> ---
>  drivers/crypto/qce/core.c | 35 ++++++++++++++++++++++++++++-------
>  drivers/crypto/qce/core.h |  1 +
>  2 files changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> index 80b75085c265..92a0ff1d357e 100644
> --- a/drivers/crypto/qce/core.c
> +++ b/drivers/crypto/qce/core.c
> @@ -5,6 +5,7 @@
>  
>  #include <linux/clk.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/interconnect.h>
>  #include <linux/interrupt.h>
>  #include <linux/module.h>
>  #include <linux/mod_devicetable.h>
> @@ -21,6 +22,8 @@
>  #define QCE_MAJOR_VERSION5	0x05
>  #define QCE_QUEUE_LENGTH	1
>  
> +#define QCE_DEFAULT_MEM_BANDWIDTH	393600

Do we know what this rate is?

> +
>  static const struct qce_algo_ops *qce_ops[] = {
>  #ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
>  	&skcipher_ops,
> @@ -202,21 +205,35 @@ static int qce_crypto_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> +	qce->mem_path = of_icc_get(qce->dev, "memory");

Using devm_of_icc_get() would save you some changes to the error path.

> +	if (IS_ERR(qce->mem_path))
> +		return PTR_ERR(qce->mem_path);
> +
>  	qce->core = devm_clk_get(qce->dev, "core");
> -	if (IS_ERR(qce->core))
> -		return PTR_ERR(qce->core);
> +	if (IS_ERR(qce->core)) {
> +		ret = PTR_ERR(qce->core);
> +		goto err_mem_path_put;
> +	}
>  
>  	qce->iface = devm_clk_get(qce->dev, "iface");
> -	if (IS_ERR(qce->iface))
> -		return PTR_ERR(qce->iface);
> +	if (IS_ERR(qce->iface)) {
> +		ret = PTR_ERR(qce->iface);
> +		goto err_mem_path_put;
> +	}
>  
>  	qce->bus = devm_clk_get(qce->dev, "bus");
> -	if (IS_ERR(qce->bus))
> -		return PTR_ERR(qce->bus);
> +	if (IS_ERR(qce->bus)) {
> +		ret = PTR_ERR(qce->bus);
> +		goto err_mem_path_put;
> +	}
> +
> +	ret = icc_set_bw(qce->mem_path, QCE_DEFAULT_MEM_BANDWIDTH, QCE_DEFAULT_MEM_BANDWIDTH);
> +	if (ret)
> +		goto err_mem_path_put;
>  
>  	ret = clk_prepare_enable(qce->core);
>  	if (ret)
> -		return ret;
> +		goto err_mem_path_disable;
>  
>  	ret = clk_prepare_enable(qce->iface);
>  	if (ret)
> @@ -256,6 +273,10 @@ static int qce_crypto_probe(struct platform_device *pdev)
>  	clk_disable_unprepare(qce->iface);
>  err_clks_core:
>  	clk_disable_unprepare(qce->core);
> +err_mem_path_disable:
> +	icc_set_bw(qce->mem_path, 0, 0);

When you icc_put() (or devm_of_icc_get() does it for you) the path's
votes are implicitly set to 0, so you don't need to do this.

And as such, you don't need to change the error path at all.

Regards,
Bjorn

> +err_mem_path_put:
> +	icc_put(qce->mem_path);
>  	return ret;
>  }
>  
> diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
> index 085774cdf641..228fcd69ec51 100644
> --- a/drivers/crypto/qce/core.h
> +++ b/drivers/crypto/qce/core.h
> @@ -35,6 +35,7 @@ struct qce_device {
>  	void __iomem *base;
>  	struct device *dev;
>  	struct clk *core, *iface, *bus;
> +	struct icc_path *mem_path;
>  	struct qce_dma_data dma;
>  	int burst_size;
>  	unsigned int pipe_pair_id;
> -- 
> 2.30.2
>
Thara Gopinath May 18, 2021, 3:38 p.m. UTC | #13 
On 5/18/21 11:07 AM, Bjorn Andersson wrote:
> On Wed 05 May 16:37 CDT 2021, Bhupesh Sharma wrote:
> 
>> From: Thara Gopinath <thara.gopinath@linaro.org>
>>
>> Crypto engine on certain Snapdragon processors like sm8150, sm8250, sm8350
>> etc. requires interconnect path between the engine and memory to be
>> explicitly enabled and bandwidth set prior to any operations. Add support
>> in the qce core to enable the interconnect path appropriately.
>>
>> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Andy Gross <agross@kernel.org>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Stephen Boyd <sboyd@kernel.org>
>> Cc: Michael Turquette <mturquette@baylibre.com>
>> Cc: Vinod Koul <vkoul@kernel.org>
>> Cc: dmaengine@vger.kernel.org
>> Cc: linux-clk@vger.kernel.org
>> Cc: linux-crypto@vger.kernel.org
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: bhupesh.linux@gmail.com
>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>> [Make header file inclusion alphabetical]
>> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
> 
> This says that you prepared the patch, then Thara picked up the patch
> and sorted the includes. But somehow you then sent the patch.
> 
> I.e. you name should be the last - unless you jointly wrote the path, in
> which case you should also add a "Co-developed-by: Thara".
> 
>> ---
>>   drivers/crypto/qce/core.c | 35 ++++++++++++++++++++++++++++-------
>>   drivers/crypto/qce/core.h |  1 +
>>   2 files changed, 29 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
>> index 80b75085c265..92a0ff1d357e 100644
>> --- a/drivers/crypto/qce/core.c
>> +++ b/drivers/crypto/qce/core.c
>> @@ -5,6 +5,7 @@
>>   
>>   #include <linux/clk.h>
>>   #include <linux/dma-mapping.h>
>> +#include <linux/interconnect.h>
>>   #include <linux/interrupt.h>
>>   #include <linux/module.h>
>>   #include <linux/mod_devicetable.h>
>> @@ -21,6 +22,8 @@
>>   #define QCE_MAJOR_VERSION5	0x05
>>   #define QCE_QUEUE_LENGTH	1
>>   
>> +#define QCE_DEFAULT_MEM_BANDWIDTH	393600
> 
> Do we know what this rate is?
> 
>> +
>>   static const struct qce_algo_ops *qce_ops[] = {
>>   #ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
>>   	&skcipher_ops,
>> @@ -202,21 +205,35 @@ static int qce_crypto_probe(struct platform_device *pdev)
>>   	if (ret < 0)
>>   		return ret;
>>   
>> +	qce->mem_path = of_icc_get(qce->dev, "memory");
> 
> Using devm_of_icc_get() would save you some changes to the error path.

Right. I keep forgetting to use the devm_ version! Bhupesh, will you do 
these changes or do you want me to ?
Bhupesh Sharma May 18, 2021, 3:39 p.m. UTC | #14 
Hi Bjorn,

Thanks for the review.

On Tue, 18 May 2021 at 20:37, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Wed 05 May 16:37 CDT 2021, Bhupesh Sharma wrote:
>
> > From: Thara Gopinath <thara.gopinath@linaro.org>
> >
> > Crypto engine on certain Snapdragon processors like sm8150, sm8250, sm8350
> > etc. requires interconnect path between the engine and memory to be
> > explicitly enabled and bandwidth set prior to any operations. Add support
> > in the qce core to enable the interconnect path appropriately.
> >
> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Andy Gross <agross@kernel.org>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Cc: dmaengine@vger.kernel.org
> > Cc: linux-clk@vger.kernel.org
> > Cc: linux-crypto@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: bhupesh.linux@gmail.com
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> > [Make header file inclusion alphabetical]
> > Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org>
>
> This says that you prepared the patch, then Thara picked up the patch
> and sorted the includes. But somehow you then sent the patch.
>
> I.e. you name should be the last - unless you jointly wrote the path, in
> which case you should also add a "Co-developed-by: Thara".

No, it's the other way around. Thara prepared the patch (as the
'From:' field suggests) and I just changed the inclusion order of the
header files and made it in alphabetical order.

I will move my S-o-b later in the order.

> > ---
> >  drivers/crypto/qce/core.c | 35 ++++++++++++++++++++++++++++-------
> >  drivers/crypto/qce/core.h |  1 +
> >  2 files changed, 29 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> > index 80b75085c265..92a0ff1d357e 100644
> > --- a/drivers/crypto/qce/core.c
> > +++ b/drivers/crypto/qce/core.c
> > @@ -5,6 +5,7 @@
> >
> >  #include <linux/clk.h>
> >  #include <linux/dma-mapping.h>
> > +#include <linux/interconnect.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/module.h>
> >  #include <linux/mod_devicetable.h>
> > @@ -21,6 +22,8 @@
> >  #define QCE_MAJOR_VERSION5   0x05
> >  #define QCE_QUEUE_LENGTH     1
> >
> > +#define QCE_DEFAULT_MEM_BANDWIDTH    393600
>
> Do we know what this rate is?

I think this corresponds to the arbitrated bandwidth / instantaneous
bandwidth (in KBps)
for the qce crypto part [I think 'average/peak bandwidth' would be a
better terminology :) ].

Maybe Thara can add more comments here.

> > +
> >  static const struct qce_algo_ops *qce_ops[] = {
> >  #ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
> >       &skcipher_ops,
> > @@ -202,21 +205,35 @@ static int qce_crypto_probe(struct platform_device *pdev)
> >       if (ret < 0)
> >               return ret;
> >
> > +     qce->mem_path = of_icc_get(qce->dev, "memory");
>
> Using devm_of_icc_get() would save you some changes to the error path.

Ok, I can address this in v3.

> > +     if (IS_ERR(qce->mem_path))
> > +             return PTR_ERR(qce->mem_path);
> > +
> >       qce->core = devm_clk_get(qce->dev, "core");
> > -     if (IS_ERR(qce->core))
> > -             return PTR_ERR(qce->core);
> > +     if (IS_ERR(qce->core)) {
> > +             ret = PTR_ERR(qce->core);
> > +             goto err_mem_path_put;
> > +     }
> >
> >       qce->iface = devm_clk_get(qce->dev, "iface");
> > -     if (IS_ERR(qce->iface))
> > -             return PTR_ERR(qce->iface);
> > +     if (IS_ERR(qce->iface)) {
> > +             ret = PTR_ERR(qce->iface);
> > +             goto err_mem_path_put;
> > +     }
> >
> >       qce->bus = devm_clk_get(qce->dev, "bus");
> > -     if (IS_ERR(qce->bus))
> > -             return PTR_ERR(qce->bus);
> > +     if (IS_ERR(qce->bus)) {
> > +             ret = PTR_ERR(qce->bus);
> > +             goto err_mem_path_put;
> > +     }
> > +
> > +     ret = icc_set_bw(qce->mem_path, QCE_DEFAULT_MEM_BANDWIDTH, QCE_DEFAULT_MEM_BANDWIDTH);
> > +     if (ret)
> > +             goto err_mem_path_put;
> >
> >       ret = clk_prepare_enable(qce->core);
> >       if (ret)
> > -             return ret;
> > +             goto err_mem_path_disable;
> >
> >       ret = clk_prepare_enable(qce->iface);
> >       if (ret)
> > @@ -256,6 +273,10 @@ static int qce_crypto_probe(struct platform_device *pdev)
> >       clk_disable_unprepare(qce->iface);
> >  err_clks_core:
> >       clk_disable_unprepare(qce->core);
> > +err_mem_path_disable:
> > +     icc_set_bw(qce->mem_path, 0, 0);
>
> When you icc_put() (or devm_of_icc_get() does it for you) the path's
> votes are implicitly set to 0, so you don't need to do this.
>
> And as such, you don't need to change the error path at all.

Ok, got it. Will change v3 accordingly.

Thanks,
Bhupesh

> > +err_mem_path_put:
> > +     icc_put(qce->mem_path);
> >       return ret;
> >  }
> >
> > diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
> > index 085774cdf641..228fcd69ec51 100644
> > --- a/drivers/crypto/qce/core.h
> > +++ b/drivers/crypto/qce/core.h
> > @@ -35,6 +35,7 @@ struct qce_device {
> >       void __iomem *base;
> >       struct device *dev;
> >       struct clk *core, *iface, *bus;
> > +     struct icc_path *mem_path;
> >       struct qce_dma_data dma;
> >       int burst_size;
> >       unsigned int pipe_pair_id;
> > --
> > 2.30.2
> >