[PATCH v8 0/9] crypto: qcom-qce: Add YAML bindings & support for newer SoCs

[PATCH v8 0/9] crypto: qcom-qce: Add YAML bindings & support for newer SoCs

[Vladimir Zapolskiy]

The series contains Qualcomm Crypto Engine dts and driver changes,
which modify a set of accepted compatible property values, this is
needed to provide a unified and fine-grained support of the driver
on old and new platforms. In addition due to QCE IP changes on new
Qualcomm platforms, it is reflected in updates to valid device tree
properties, namely added iommu, interconnects and optional clocks.

Changes since v7:
=================
- v7 can be found here: https://lore.kernel.org/linux-arm-msm/20220920114051.1116441-1-bhupesh.sharma@linaro.org
- Added a change by Neil Armstrong to document clocks and clock-names
  properties as optional,
- At the moment do not add Bhupesh as a new QCE driver maintainer,
- Minor updates to device tree binding documentation and qce driver,
  in particular added more compatibles and fixed lesser issues.

Changes since v6:
=================
- v6 can be seen here: https://lore.kernel.org/linux-arm-msm/30756e6f-952f-ccf2-b493-e515ba4f0a64@linaro.org/
- As per Krzysztof's suggestion on v6, clubbed the crypto driver and
  dt-bindings changes together. Now the overall v5 patchset into 3
  separate patchsets, one each for the following areas to allow easier
  review and handling from the maintainer:
	arm-msm, crypto and dma

Changes since v5:
=================
- v5 can be seen here: https://lore.kernel.org/lkml/20211110105922.217895-1-bhupesh.sharma@linaro.org/
- As per Bjorn's suggestion on irc, broke down the patchset into 4
  separate patchsets, one each for the following areas to allow easier
  review and handling from the maintainer:
	arm-msm, crypto, dma and devicetree
- Addressed Rob's, Vladimir's and Bjorn's review comments received on
  v5.
- Added Tested-by from Jordan received on the v5.

Changes since v4:
=================
- v4 for sm8250 can be seen here: https://lore.kernel.org/linux-arm-msm/20211013105541.68045-1-bhupesh.sharma@linaro.org/
- v1 for sm8150 qce enablement can be seen here: https://lore.kernel.org/linux-arm-msm/20211013165823.88123-1-bhupesh.sharma@linaro.org/
- Merged the sm8150 and sm8250 enablement patches in the same patchset,
  as per suggestions from Bjorn.
- Dropped a couple of patches from v4, as these have been picked by
  Bjorn already via his tree.
- Addressed review comments from Vladimir, Thara and Rob.
- Collect Reviewed-by from Rob and Thara on some of the patches from the
  v4 patchset.

Changes since v3:
=================
- v3 can be seen here: https://lore.kernel.org/linux-arm-msm/20210519143700.27392-1-bhupesh.sharma@linaro.org/
- Dropped a couple of patches from v3, on basis of the review comments:
   ~ [PATCH 13/17] crypto: qce: core: Make clocks optional
   ~ [PATCH 15/17] crypto: qce: Convert the device found dev_dbg() to dev_info()
- Addressed review comments from Thara, Rob and Stephan Gerhold.
- Collect Reviewed-by from Rob and Thara on some of the patches from the
  v3 patchset.

Changes since v2:
=================
- v2 can be seen here: https://lore.kernel.org/dmaengine/20210505213731.538612-1-bhupesh.sharma@linaro.org/
- Drop a couple of patches from v1, which tried to address the defered
  probing of qce driver in case bam dma driver is not yet probed.
  Replace it instead with a single (simpler) patch [PATCH 16/17].
- Convert bam dma and qce crypto dt-bindings to YAML.
- Addressed review comments from Thara, Bjorn, Vinod and Rob.

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 (qce) is available on several Snapdragon SoCs.
The qce block 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.

Bhupesh Sharma (6):
  dt-bindings: qcom-qce: Convert bindings to yaml
  MAINTAINERS: Add qcom-qce dt-binding file to QUALCOMM CRYPTO DRIVERS section
  dt-bindings: qcom-qce: Add 'interconnects' and 'interconnect-names'
  dt-bindings: qcom-qce: Add 'iommus' to optional properties
  dt-bindings: qcom-qce: Add new SoC compatible strings for qcom-qce
  crypto: qce: core: Add new compatibles for qce crypto driver

Neil Armstrong (1):
  dt-bindings: qcom-qce: document clocks and clock-names as optional

Thara Gopinath (2):
  crypto: qce: core: Add support to initialize interconnect path
  crypto: qce: core: Make clocks optional

 .../devicetree/bindings/crypto/qcom-qce.txt   | 25 -----
 .../devicetree/bindings/crypto/qcom-qce.yaml  | 98 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 drivers/crypto/qce/core.c                     | 34 ++++++-
 drivers/crypto/qce/core.h                     |  1 +
 5 files changed, 130 insertions(+), 29 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/crypto/qcom-qce.txt
 create mode 100644 Documentation/devicetree/bindings/crypto/qcom-qce.yaml

-- 
2.33.0

[PATCH v8 1/9] dt-bindings: qcom-qce: Convert bindings to yaml

[Vladimir Zapolskiy]

From: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Convert Qualcomm QCE crypto devicetree binding to YAML.

Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 .../devicetree/bindings/crypto/qcom-qce.txt   | 25 -------
 .../devicetree/bindings/crypto/qcom-qce.yaml  | 67 +++++++++++++++++++
 2 files changed, 67 insertions(+), 25 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/crypto/qcom-qce.txt
 create mode 100644 Documentation/devicetree/bindings/crypto/qcom-qce.yaml

diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.txt b/Documentation/devicetree/bindings/crypto/qcom-qce.txt
deleted file mode 100644
index fdd53b184ba8..000000000000
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Qualcomm crypto engine driver
-
-Required properties:
-
-- compatible  : should be "qcom,crypto-v5.1"
-- reg         : specifies base physical address and size of the registers map
-- clocks      : phandle to clock-controller plus clock-specifier pair
-- clock-names : "iface" clocks register interface
-                "bus" clocks data transfer interface
-                "core" clocks rest of the crypto block
-- dmas        : DMA specifiers for tx and rx dma channels. For more see
-                Documentation/devicetree/bindings/dma/dma.txt
-- dma-names   : DMA request names should be "rx" and "tx"
-
-Example:
-	crypto@fd45a000 {
-		compatible = "qcom,crypto-v5.1";
-		reg = <0xfd45a000 0x6000>;
-		clocks = <&gcc GCC_CE2_AHB_CLK>,
-			 <&gcc GCC_CE2_AXI_CLK>,
-			 <&gcc GCC_CE2_CLK>;
-		clock-names = "iface", "bus", "core";
-		dmas = <&cryptobam 2>, <&cryptobam 3>;
-		dma-names = "rx", "tx";
-	};
diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
new file mode 100644
index 000000000000..8df47e8513b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/qcom-qce.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm crypto engine driver
+
+maintainers:
+  - Bhupesh Sharma <bhupesh.sharma@linaro.org>
+
+description:
+  This document defines the binding for the QCE crypto
+  controller found on Qualcomm parts.
+
+properties:
+  compatible:
+    const: qcom,crypto-v5.1
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: iface clocks register interface.
+      - description: bus clocks data transfer interface.
+      - description: core clocks rest of the crypto block.
+
+  clock-names:
+    items:
+      - const: iface
+      - const: bus
+      - const: core
+
+  dmas:
+    items:
+      - description: DMA specifiers for rx dma channel.
+      - description: DMA specifiers for tx dma channel.
+
+  dma-names:
+    items:
+      - const: rx
+      - const: tx
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - dmas
+  - dma-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/qcom,gcc-apq8084.h>
+    crypto-engine@fd45a000 {
+        compatible = "qcom,crypto-v5.1";
+        reg = <0xfd45a000 0x6000>;
+        clocks = <&gcc GCC_CE2_AHB_CLK>,
+                 <&gcc GCC_CE2_AXI_CLK>,
+                 <&gcc GCC_CE2_CLK>;
+        clock-names = "iface", "bus", "core";
+        dmas = <&cryptobam 2>, <&cryptobam 3>;
+        dma-names = "rx", "tx";
+    };
-- 
2.33.0

[PATCH v8 2/9] MAINTAINERS: Add qcom-qce dt-binding file to QUALCOMM CRYPTO DRIVERS section

[Vladimir Zapolskiy]

From: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Add the entry for 'Documentation/devicetree/bindings/crypto/qcom-qce.yaml'
to the appropriate section for 'QUALCOMM CRYPTO DRIVERS' in
MAINTAINERS file.

Cc: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 590bcd047a7f..5530f07d1c31 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17196,6 +17196,7 @@ M:	Thara Gopinath <thara.gopinath@gmail.com>
 L:	linux-crypto@vger.kernel.org
 L:	linux-arm-msm@vger.kernel.org
 S:	Maintained
+F:	Documentation/devicetree/bindings/crypto/qcom-qce.yaml
 F:	drivers/crypto/qce/
 
 QUALCOMM EMAC GIGABIT ETHERNET DRIVER
-- 
2.33.0

Re: [PATCH v8 2/9] MAINTAINERS: Add qcom-qce dt-binding file to QUALCOMM CRYPTO DRIVERS section

[Bjorn Andersson]

On Thu, Feb 02, 2023 at 03:50:29PM +0200, Vladimir Zapolskiy wrote:
> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> 
> Add the entry for 'Documentation/devicetree/bindings/crypto/qcom-qce.yaml'
> to the appropriate section for 'QUALCOMM CRYPTO DRIVERS' in
> MAINTAINERS file.
> 
> Cc: Bjorn Andersson <andersson@kernel.org>

Reviewed-by: Bjorn Andersson <andersson@kernel.org>

> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 590bcd047a7f..5530f07d1c31 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17196,6 +17196,7 @@ M:	Thara Gopinath <thara.gopinath@gmail.com>
>  L:	linux-crypto@vger.kernel.org
>  L:	linux-arm-msm@vger.kernel.org
>  S:	Maintained
> +F:	Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>  F:	drivers/crypto/qce/
>  
>  QUALCOMM EMAC GIGABIT ETHERNET DRIVER
> -- 
> 2.33.0
> 

[PATCH v8 3/9] dt-bindings: qcom-qce: Add 'interconnects' and 'interconnect-names'

[Vladimir Zapolskiy]

From: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Add 'interconnects' and 'interconnect-names' as optional properties
to the device-tree binding documentation for Qualcomm crypto IP.

These properties describe the interconnect path between crypto and main
memory and the interconnect type respectively.

Cc: Bjorn Andersson <andersson@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index 8df47e8513b8..94f96ebc5dac 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -32,6 +32,14 @@ properties:
       - const: bus
       - const: core
 
+  interconnects:
+    maxItems: 1
+    description:
+      Interconnect path between qce crypto and main memory.
+
+  interconnect-names:
+    const: memory
+
   dmas:
     items:
       - description: DMA specifiers for rx dma channel.
-- 
2.33.0

[PATCH v8 4/9] dt-bindings: qcom-qce: Add 'iommus' to optional properties

[Vladimir Zapolskiy]

From: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Add the missing optional property - 'iommus' to the
device-tree binding documentation for qcom-qce crypto IP.

This property describes the phandle(s) to apps_smmu node with sid mask.

Cc: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index 94f96ebc5dac..4e00e7925fed 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -32,6 +32,12 @@ properties:
       - const: bus
       - const: core
 
+  iommus:
+    minItems: 1
+    maxItems: 8
+    description:
+      phandle to apps_smmu node with sid mask.
+
   interconnects:
     maxItems: 1
     description:
@@ -72,4 +78,8 @@ examples:
         clock-names = "iface", "bus", "core";
         dmas = <&cryptobam 2>, <&cryptobam 3>;
         dma-names = "rx", "tx";
+        iommus = <&apps_smmu 0x584 0x0011>,
+                 <&apps_smmu 0x586 0x0011>,
+                 <&apps_smmu 0x594 0x0011>,
+                 <&apps_smmu 0x596 0x0011>;
     };
-- 
2.33.0

[PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Vladimir Zapolskiy]

From: Neil Armstrong <neil.armstrong@linaro.org>

On certain Snapdragon processors, the crypto engine clocks are enabled by
default by security firmware.

Drop clocks and clock-names from the required properties list.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index 4e00e7925fed..a159089e8a6a 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -59,8 +59,6 @@ properties:
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
   - dmas
   - dma-names
 
-- 
2.33.0

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Krzysztof Kozlowski]

On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
> From: Neil Armstrong <neil.armstrong@linaro.org>
> 
> On certain Snapdragon processors, the crypto engine clocks are enabled by
> default by security firmware.

Then probably we should not require them only on these variants.

Best regards,
Krzysztof

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Vladimir Zapolskiy]

Hi Krzysztof,

On 2/2/23 15:53, Krzysztof Kozlowski wrote:
> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>
>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>> default by security firmware.
> 
> Then probably we should not require them only on these variants.

I don't have the exact list of the affected SoCs, I believe Neil can provide
such a list, if you find it crucial.

--
Best wishes,
Vladimir

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Neil Armstrong]

On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
> 
> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>
>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>> default by security firmware.
>>
>> Then probably we should not require them only on these variants.
> 
> I don't have the exact list of the affected SoCs, I believe Neil can provide
> such a list, if you find it crucial.

It's the case for SM8350, SM8450 & SM8550.

Neil

> 
> -- 
> Best wishes,
> Vladimir

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Krzysztof Kozlowski]

On 02/02/2023 15:21, Neil Armstrong wrote:
> On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
>> Hi Krzysztof,
>>
>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>
>>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>>> default by security firmware.
>>>
>>> Then probably we should not require them only on these variants.
>>
>> I don't have the exact list of the affected SoCs, I believe Neil can provide
>> such a list, if you find it crucial.
> 
> It's the case for SM8350, SM8450 & SM8550.

So let's keep them required for explicit list of compatibles (older
devices).

Best regards,
Krzysztof

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Vladimir Zapolskiy]

On 2/2/23 16:21, Neil Armstrong wrote:
> On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
>> Hi Krzysztof,
>>
>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>
>>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>>> default by security firmware.
>>>
>>> Then probably we should not require them only on these variants.
>>
>> I don't have the exact list of the affected SoCs, I believe Neil can provide
>> such a list, if you find it crucial.
> 
> It's the case for SM8350, SM8450 & SM8550.
> 

On SM8250 there is no QCE clocks also, so I'll add it to the list, and I hope
that now the list is complete.

It could be that the relevant platforms are the ones with 'qcom,no-clock-support'
property of QCE in the downstream.

-- 
Best wishes,
Vladimir

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Neil Armstrong]

On 02/02/2023 17:16, Vladimir Zapolskiy wrote:
> On 2/2/23 16:21, Neil Armstrong wrote:
>> On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
>>> Hi Krzysztof,
>>>
>>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>>
>>>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>>>> default by security firmware.
>>>>
>>>> Then probably we should not require them only on these variants.
>>>
>>> I don't have the exact list of the affected SoCs, I believe Neil can provide
>>> such a list, if you find it crucial.
>>
>> It's the case for SM8350, SM8450 & SM8550.
>>
> 
> On SM8250 there is no QCE clocks also, so I'll add it to the list, and I hope
> that now the list is complete.
> 
> It could be that the relevant platforms are the ones with 'qcom,no-clock-support'
> property of QCE in the downstream.
> 

Yes this is what I figured out with the 5.10 device-trees I have checkouted.

Neil

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Dmitry Baryshkov]

On 02/02/2023 18:16, Vladimir Zapolskiy wrote:
> On 2/2/23 16:21, Neil Armstrong wrote:
>> On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
>>> Hi Krzysztof,
>>>
>>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>>
>>>>> On certain Snapdragon processors, the crypto engine clocks are 
>>>>> enabled by
>>>>> default by security firmware.
>>>>
>>>> Then probably we should not require them only on these variants.
>>>
>>> I don't have the exact list of the affected SoCs, I believe Neil can 
>>> provide
>>> such a list, if you find it crucial.
>>
>> It's the case for SM8350, SM8450 & SM8550.
>>
> 
> On SM8250 there is no QCE clocks also, so I'll add it to the list, and I 
> hope
> that now the list is complete.
> 
> It could be that the relevant platforms are the ones with 
> 'qcom,no-clock-support'
> property of QCE in the downstream.
> 

Then, sc7180, sc8180x, sdx55, sm6150, sm7150, sm8150 also have this 
property in QCE device. And, I think, it should also be applicable to 
sc7280 and sc8280xp.

-- 
With best wishes
Dmitry

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Vladimir Zapolskiy]

On 2/7/23 01:45, Dmitry Baryshkov wrote:
> On 02/02/2023 18:16, Vladimir Zapolskiy wrote:
>> On 2/2/23 16:21, Neil Armstrong wrote:
>>> On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>>>
>>>>>> On certain Snapdragon processors, the crypto engine clocks are
>>>>>> enabled by
>>>>>> default by security firmware.
>>>>>
>>>>> Then probably we should not require them only on these variants.
>>>>
>>>> I don't have the exact list of the affected SoCs, I believe Neil can
>>>> provide
>>>> such a list, if you find it crucial.
>>>
>>> It's the case for SM8350, SM8450 & SM8550.
>>>
>>
>> On SM8250 there is no QCE clocks also, so I'll add it to the list, and I
>> hope
>> that now the list is complete.
>>
>> It could be that the relevant platforms are the ones with
>> 'qcom,no-clock-support'
>> property of QCE in the downstream.
>>
> 
> Then, sc7180, sc8180x, sdx55, sm6150, sm7150, sm8150 also have this
> property in QCE device. And, I think, it should also be applicable to
> sc7280 and sc8280xp.

So maybe do you have a better candidate among the SoCs for a QCE IP family
name than SM8150 based? Likely it could be the first released SoC among
mentioned above.

--
Best wishes,
Vladimir

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Krzysztof Kozlowski]

On 10/02/2023 12:12, Vladimir Zapolskiy wrote:
> On 2/7/23 01:45, Dmitry Baryshkov wrote:
>> On 02/02/2023 18:16, Vladimir Zapolskiy wrote:
>>> On 2/2/23 16:21, Neil Armstrong wrote:
>>>> On 02/02/2023 15:04, Vladimir Zapolskiy wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>>>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>>>>
>>>>>>> On certain Snapdragon processors, the crypto engine clocks are
>>>>>>> enabled by
>>>>>>> default by security firmware.
>>>>>>
>>>>>> Then probably we should not require them only on these variants.
>>>>>
>>>>> I don't have the exact list of the affected SoCs, I believe Neil can
>>>>> provide
>>>>> such a list, if you find it crucial.
>>>>
>>>> It's the case for SM8350, SM8450 & SM8550.
>>>>
>>>
>>> On SM8250 there is no QCE clocks also, so I'll add it to the list, and I
>>> hope
>>> that now the list is complete.
>>>
>>> It could be that the relevant platforms are the ones with
>>> 'qcom,no-clock-support'
>>> property of QCE in the downstream.
>>>
>>
>> Then, sc7180, sc8180x, sdx55, sm6150, sm7150, sm8150 also have this
>> property in QCE device. And, I think, it should also be applicable to
>> sc7280 and sc8280xp.
> 
> So maybe do you have a better candidate among the SoCs for a QCE IP family
> name than SM8150 based? Likely it could be the first released SoC among
> mentioned above.

If you have access to the docs, you will see clear mapping of version to
the SoCs. Just choose the oldest SoC from the list (or something looking
as the oldest - there is no need to be very accurate).


Best regards,
Krzysztof

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Vladimir Zapolskiy]

Hi Krzysztof,

On 2/2/23 15:53, Krzysztof Kozlowski wrote:
> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>
>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>> default by security firmware.
> 
> Then probably we should not require them only on these variants.

the rationale is clear, but here comes a minor problem, older platforms
require clocks, when newer ones do not. When a generic SoC-specific compatible
is introduced, let say "qcom,ipq4019-qce", it itself requires the clocks,
but then newer platforms can not be based on this particular compatible,
otherwise they will require clocks and this comes as invalid.

How to resolve it properly, shall there be another generic SoC-specific
compatible without clocks and NOT based on that "qcom,ipq4019-qce" compatible?

By the way, QCE on SM8150 also shall not need the clocks.

--
Best wishes,
Vladimir

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Krzysztof Kozlowski]

On 02/02/2023 23:27, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
> 
> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>
>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>> default by security firmware.
>>
>> Then probably we should not require them only on these variants.
> 
> the rationale is clear, but here comes a minor problem, older platforms
> require clocks, when newer ones do not. When a generic SoC-specific compatible
> is introduced, let say "qcom,ipq4019-qce", it itself requires the clocks,
> but then newer platforms can not be based on this particular compatible,
> otherwise they will require clocks and this comes as invalid.
> 
> How to resolve it properly, shall there be another generic SoC-specific
> compatible without clocks and NOT based on that "qcom,ipq4019-qce" compatible?
> 
> By the way, QCE on SM8150 also shall not need the clocks.

Assuming you have:
1. ipq4019 requiring clocks
2. msm8996 compatible with ipq4019, requiring clocks
3. ipq6018 compatible with ipq4019, not requiring clocks

allOf:
  - if:
      properties:
        compatible:
          enum:
             - ipq4019-qce
    then:
      required:
        - clocks

  - if:
      properties:
        compatible:
          contains:
            enum:
               - msm8996-qce
    then:
      required:
        - clocks

That's not pretty.

Another solution is to make non-clock-requiring variants as their own
family:

1. msm8996-qce, ipq4019-qce
2. sm8550-qce, sm8150-qce

and then in the driver you need two entries - ipq4019 and sm8150.

I like the latter, because for clock-requiring variants your driver
should actually get them and require. For non-clock-requiring variants,
you just skip the clocks (do not fail). Therefore you need different
driver data for these two families.

Best regards,
Krzysztof

Re: [PATCH v8 5/9] dt-bindings: qcom-qce: document clocks and clock-names as optional

[Vladimir Zapolskiy]

Hi Krzysztof,

On 2/3/23 10:17, Krzysztof Kozlowski wrote:
> On 02/02/2023 23:27, Vladimir Zapolskiy wrote:
>> Hi Krzysztof,
>>
>> On 2/2/23 15:53, Krzysztof Kozlowski wrote:
>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>> From: Neil Armstrong <neil.armstrong@linaro.org>
>>>>
>>>> On certain Snapdragon processors, the crypto engine clocks are enabled by
>>>> default by security firmware.
>>>
>>> Then probably we should not require them only on these variants.
>>
>> the rationale is clear, but here comes a minor problem, older platforms
>> require clocks, when newer ones do not. When a generic SoC-specific compatible
>> is introduced, let say "qcom,ipq4019-qce", it itself requires the clocks,
>> but then newer platforms can not be based on this particular compatible,
>> otherwise they will require clocks and this comes as invalid.
>>
>> How to resolve it properly, shall there be another generic SoC-specific
>> compatible without clocks and NOT based on that "qcom,ipq4019-qce" compatible?
>>
>> By the way, QCE on SM8150 also shall not need the clocks.
> 
> Assuming you have:
> 1. ipq4019 requiring clocks
> 2. msm8996 compatible with ipq4019, requiring clocks
> 3. ipq6018 compatible with ipq4019, not requiring clocks
> 
> allOf:
>    - if:
>        properties:
>          compatible:
>            enum:
>               - ipq4019-qce
>      then:
>        required:
>          - clocks
> 
>    - if:
>        properties:
>          compatible:
>            contains:
>              enum:
>                 - msm8996-qce
>      then:
>        required:
>          - clocks
> 
> That's not pretty.
> 
> Another solution is to make non-clock-requiring variants as their own
> family:
> 
> 1. msm8996-qce, ipq4019-qce
> 2. sm8550-qce, sm8150-qce
> 
> and then in the driver you need two entries - ipq4019 and sm8150.
> 
> I like the latter, because for clock-requiring variants your driver
> should actually get them and require. For non-clock-requiring variants,
> you just skip the clocks (do not fail). Therefore you need different
> driver data for these two families.

many thanks for the detailed explanation, the first of two solutions will
be even more clumsy and convoluted, since there should be lists split into
two baskets.

Thus I will go with the second variant and add two family compatibles.

--
Best wishes,
Vladimir

[PATCH v8 6/9] dt-bindings: qcom-qce: Add new SoC compatible strings for qcom-qce

[Vladimir Zapolskiy]

From: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Newer Qualcomm chips support newer versions of the qce crypto IP, so add
soc specific compatible strings for qcom-qce instead of using crypto
IP version specific ones.

Keep the old strings for backward-compatibility, but mark them as
deprecated.

Cc: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 .../devicetree/bindings/crypto/qcom-qce.yaml  | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
index a159089e8a6a..4e0b63b85267 100644
--- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
@@ -15,7 +15,22 @@ description:
 
 properties:
   compatible:
-    const: qcom,crypto-v5.1
+    oneOf:
+      - const: qcom,crypto-v5.1
+        deprecated: true
+        description: Kept only for ABI backward compatibility
+      - items:
+          - enum:
+              - qcom,ipq4019-qce
+              - qcom,ipq6018-qce
+              - qcom,ipq8074-qce
+              - qcom,msm8996-qce
+              - qcom,sdm845-qce
+              - qcom,sm8150-qce
+              - qcom,sm8250-qce
+              - qcom,sm8350-qce
+              - qcom,sm8450-qce
+              - qcom,sm8550-qce
 
   reg:
     maxItems: 1
@@ -68,7 +83,7 @@ examples:
   - |
     #include <dt-bindings/clock/qcom,gcc-apq8084.h>
     crypto-engine@fd45a000 {
-        compatible = "qcom,crypto-v5.1";
+        compatible = "qcom,ipq6018-qce";
         reg = <0xfd45a000 0x6000>;
         clocks = <&gcc GCC_CE2_AHB_CLK>,
                  <&gcc GCC_CE2_AXI_CLK>,
-- 
2.33.0

Re: [PATCH v8 6/9] dt-bindings: qcom-qce: Add new SoC compatible strings for qcom-qce

[Krzysztof Kozlowski]

On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> 
> Newer Qualcomm chips support newer versions of the qce crypto IP, so add
> soc specific compatible strings for qcom-qce instead of using crypto
> IP version specific ones.
> 
> Keep the old strings for backward-compatibility, but mark them as
> deprecated.
> 
> Cc: Bjorn Andersson <andersson@kernel.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Tested-by: Jordan Crouse <jorcrous@amazon.com>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  .../devicetree/bindings/crypto/qcom-qce.yaml  | 19 +++++++++++++++++--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
> index a159089e8a6a..4e0b63b85267 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
> @@ -15,7 +15,22 @@ description:
>  
>  properties:
>    compatible:
> -    const: qcom,crypto-v5.1
> +    oneOf:
> +      - const: qcom,crypto-v5.1
> +        deprecated: true
> +        description: Kept only for ABI backward compatibility
> +      - items:

Drop items.

> +          - enum:
> +              - qcom,ipq4019-qce
> +              - qcom,ipq6018-qce
> +              - qcom,ipq8074-qce
> +              - qcom,msm8996-qce
> +              - qcom,sdm845-qce
> +              - qcom,sm8150-qce
> +              - qcom,sm8250-qce
> +              - qcom,sm8350-qce
> +              - qcom,sm8450-qce
> +              - qcom,sm8550-qce

Unfortunately my comments from v6 was not addressed, nor responded to.

We already got a public comment from community that we handle Qualcomm
bindings in a too loose way. I don't think we should be doing this (so
keep ignoring ABI), just for the sanity of cleanup.

It's fine to discuss it with me, but since v6 there was no discussion,
so let's be clear here - NAK on ABI break.

Best regards,
Krzysztof

Re: [PATCH v8 6/9] dt-bindings: qcom-qce: Add new SoC compatible strings for qcom-qce

[Vladimir Zapolskiy]

Hi Krzysztof,

On 2/2/23 15:57, Krzysztof Kozlowski wrote:
> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>
>> Newer Qualcomm chips support newer versions of the qce crypto IP, so add
>> soc specific compatible strings for qcom-qce instead of using crypto
>> IP version specific ones.
>>
>> Keep the old strings for backward-compatibility, but mark them as
>> deprecated.
>>
>> Cc: Bjorn Andersson <andersson@kernel.org>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>> ---
>>   .../devicetree/bindings/crypto/qcom-qce.yaml  | 19 +++++++++++++++++--
>>   1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>> index a159089e8a6a..4e0b63b85267 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>> @@ -15,7 +15,22 @@ description:
>>   
>>   properties:
>>     compatible:
>> -    const: qcom,crypto-v5.1
>> +    oneOf:
>> +      - const: qcom,crypto-v5.1
>> +        deprecated: true
>> +        description: Kept only for ABI backward compatibility
>> +      - items:
> 
> Drop items.
> 
>> +          - enum:
>> +              - qcom,ipq4019-qce
>> +              - qcom,ipq6018-qce
>> +              - qcom,ipq8074-qce
>> +              - qcom,msm8996-qce
>> +              - qcom,sdm845-qce
>> +              - qcom,sm8150-qce
>> +              - qcom,sm8250-qce
>> +              - qcom,sm8350-qce
>> +              - qcom,sm8450-qce
>> +              - qcom,sm8550-qce
> 
> Unfortunately my comments from v6 was not addressed, nor responded to.
> 
> We already got a public comment from community that we handle Qualcomm
> bindings in a too loose way. I don't think we should be doing this (so
> keep ignoring ABI), just for the sanity of cleanup.
> 
> It's fine to discuss it with me, but since v6 there was no discussion,
> so let's be clear here - NAK on ABI break.

Can you please elaborate, what is the ABI break you find here?

As for me it looks like an incremental change, thus I don't understand
your comment why ABI is broken.

--
Best wishes,
Vladimir

Re: [PATCH v8 6/9] dt-bindings: qcom-qce: Add new SoC compatible strings for qcom-qce

[Krzysztof Kozlowski]

On 02/02/2023 15:09, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
> 
> On 2/2/23 15:57, Krzysztof Kozlowski wrote:
>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>>
>>> Newer Qualcomm chips support newer versions of the qce crypto IP, so add
>>> soc specific compatible strings for qcom-qce instead of using crypto
>>> IP version specific ones.
>>>
>>> Keep the old strings for backward-compatibility, but mark them as
>>> deprecated.
>>>
>>> Cc: Bjorn Andersson <andersson@kernel.org>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>> ---
>>>   .../devicetree/bindings/crypto/qcom-qce.yaml  | 19 +++++++++++++++++--
>>>   1 file changed, 17 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>>> index a159089e8a6a..4e0b63b85267 100644
>>> --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>>> +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml
>>> @@ -15,7 +15,22 @@ description:
>>>   
>>>   properties:
>>>     compatible:
>>> -    const: qcom,crypto-v5.1
>>> +    oneOf:
>>> +      - const: qcom,crypto-v5.1
>>> +        deprecated: true
>>> +        description: Kept only for ABI backward compatibility
>>> +      - items:
>>
>> Drop items.
>>
>>> +          - enum:
>>> +              - qcom,ipq4019-qce
>>> +              - qcom,ipq6018-qce
>>> +              - qcom,ipq8074-qce
>>> +              - qcom,msm8996-qce
>>> +              - qcom,sdm845-qce
>>> +              - qcom,sm8150-qce
>>> +              - qcom,sm8250-qce
>>> +              - qcom,sm8350-qce
>>> +              - qcom,sm8450-qce
>>> +              - qcom,sm8550-qce
>>
>> Unfortunately my comments from v6 was not addressed, nor responded to.
>>
>> We already got a public comment from community that we handle Qualcomm
>> bindings in a too loose way. I don't think we should be doing this (so
>> keep ignoring ABI), just for the sanity of cleanup.
>>
>> It's fine to discuss it with me, but since v6 there was no discussion,
>> so let's be clear here - NAK on ABI break.
> 
> Can you please elaborate, what is the ABI break you find here?
> 
> As for me it looks like an incremental change, thus I don't understand
> your comment why ABI is broken.

Right, the driver keeps the old one compatible, I missed that, so it
actually implements what I asked for in v7. It's fine then from ABI
point of view.

The remaining trouble is that any user of DTS (other systems, firmware,
bootloader) is going to be broken when taking the new DTS. But it's not
critical.

Best regards,
Krzysztof

[PATCH v8 7/9] crypto: qce: core: Add support to initialize interconnect path

[Vladimir Zapolskiy]

From: Thara Gopinath <thara.gopinath@gmail.com>

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 <andersson@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: herbert@gondor.apana.org.au
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Thara Gopinath <thara.gopinath@gmail.com>
[Bhupesh: Make header file inclusion alphabetical and use devm_of_icc_get()]
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[vladimir: moved icc bandwidth setup closer to its acquisition]
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 drivers/crypto/qce/core.c | 16 +++++++++++++++-
 drivers/crypto/qce/core.h |  1 +
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index d3780be44a76..336edba2513e 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>
@@ -22,6 +23,8 @@
 #define QCE_MAJOR_VERSION5	0x05
 #define QCE_QUEUE_LENGTH	1
 
+#define QCE_DEFAULT_MEM_BANDWIDTH	393600
+
 static const struct qce_algo_ops *qce_ops[] = {
 #ifdef CONFIG_CRYPTO_DEV_QCE_SKCIPHER
 	&skcipher_ops,
@@ -218,10 +221,18 @@ static int qce_crypto_probe(struct platform_device *pdev)
 	if (IS_ERR(qce->bus))
 		return PTR_ERR(qce->bus);
 
-	ret = clk_prepare_enable(qce->core);
+	qce->mem_path = devm_of_icc_get(qce->dev, "memory");
+	if (IS_ERR(qce->mem_path))
+		return PTR_ERR(qce->mem_path);
+
+	ret = icc_set_bw(qce->mem_path, QCE_DEFAULT_MEM_BANDWIDTH, QCE_DEFAULT_MEM_BANDWIDTH);
 	if (ret)
 		return ret;
 
+	ret = clk_prepare_enable(qce->core);
+	if (ret)
+		goto err_mem_path_disable;
+
 	ret = clk_prepare_enable(qce->iface);
 	if (ret)
 		goto err_clks_core;
@@ -260,6 +271,9 @@ 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);
+
 	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.33.0

[PATCH v8 8/9] crypto: qce: core: Make clocks optional

[Vladimir Zapolskiy]

From: Thara Gopinath <thara.gopinath@gmail.com>

On certain Snapdragon processors, the crypto engine clocks are enabled by
default by security firmware and the driver need not/ should not handle the
clocks. Make acquiring of all the clocks optional in crypto engine driver
so that the driver initializes properly even if no clocks are specified in
the dt.

Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: herbert@gondor.apana.org.au
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Thara Gopinath <thara.gopinath@gmail.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[Bhupesh: Massage the commit log]
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 drivers/crypto/qce/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index 336edba2513e..8e496fb2d5e2 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -209,15 +209,15 @@ static int qce_crypto_probe(struct platform_device *pdev)
 	if (ret < 0)
 		return ret;
 
-	qce->core = devm_clk_get(qce->dev, "core");
+	qce->core = devm_clk_get_optional(qce->dev, "core");
 	if (IS_ERR(qce->core))
 		return PTR_ERR(qce->core);
 
-	qce->iface = devm_clk_get(qce->dev, "iface");
+	qce->iface = devm_clk_get_optional(qce->dev, "iface");
 	if (IS_ERR(qce->iface))
 		return PTR_ERR(qce->iface);
 
-	qce->bus = devm_clk_get(qce->dev, "bus");
+	qce->bus = devm_clk_get_optional(qce->dev, "bus");
 	if (IS_ERR(qce->bus))
 		return PTR_ERR(qce->bus);
 
-- 
2.33.0

[PATCH v8 9/9] crypto: qce: core: Add new compatibles for qce crypto driver

[Vladimir Zapolskiy]

From: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Since we decided to use soc specific compatibles for describing
the qce crypto IP nodes in the device-trees, adapt the driver
now to handle the same.

Keep the old deprecated compatible strings still in the driver,
to ensure backward compatibility.

Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: herbert@gondor.apana.org.au
Tested-by: Jordan Crouse <jorcrous@amazon.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[vladimir: added more SoC specfic compatibles]
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 drivers/crypto/qce/core.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index 8e496fb2d5e2..2420a5ff44d1 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -291,8 +291,20 @@ static int qce_crypto_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id qce_crypto_of_match[] = {
+	/* Following two entries are deprecated (kept only for backward compatibility) */
 	{ .compatible = "qcom,crypto-v5.1", },
 	{ .compatible = "qcom,crypto-v5.4", },
+	/* Add compatible strings as per updated dt-bindings, here: */
+	{ .compatible = "qcom,ipq4019-qce", },
+	{ .compatible = "qcom,ipq6018-qce", },
+	{ .compatible = "qcom,ipq8074-qce", },
+	{ .compatible = "qcom,msm8996-qce", },
+	{ .compatible = "qcom,sdm845-qce", },
+	{ .compatible = "qcom,sm8150-qce", },
+	{ .compatible = "qcom,sm8250-qce", },
+	{ .compatible = "qcom,sm8350-qce", },
+	{ .compatible = "qcom,sm8450-qce", },
+	{ .compatible = "qcom,sm8550-qce", },
 	{}
 };
 MODULE_DEVICE_TABLE(of, qce_crypto_of_match);
-- 
2.33.0

Re: [PATCH v8 9/9] crypto: qce: core: Add new compatibles for qce crypto driver

[Krzysztof Kozlowski]

On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> 
> Since we decided to use soc specific compatibles for describing
> the qce crypto IP nodes in the device-trees, adapt the driver
> now to handle the same.
> 
> Keep the old deprecated compatible strings still in the driver,
> to ensure backward compatibility.
> 
> Cc: Bjorn Andersson <andersson@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: herbert@gondor.apana.org.au
> Tested-by: Jordan Crouse <jorcrous@amazon.com>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
> [vladimir: added more SoC specfic compatibles]
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  drivers/crypto/qce/core.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
> index 8e496fb2d5e2..2420a5ff44d1 100644
> --- a/drivers/crypto/qce/core.c
> +++ b/drivers/crypto/qce/core.c
> @@ -291,8 +291,20 @@ static int qce_crypto_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id qce_crypto_of_match[] = {
> +	/* Following two entries are deprecated (kept only for backward compatibility) */
>  	{ .compatible = "qcom,crypto-v5.1", },
>  	{ .compatible = "qcom,crypto-v5.4", },
> +	/* Add compatible strings as per updated dt-bindings, here: */
> +	{ .compatible = "qcom,ipq4019-qce", },
> +	{ .compatible = "qcom,ipq6018-qce", },
> +	{ .compatible = "qcom,ipq8074-qce", },
> +	{ .compatible = "qcom,msm8996-qce", },
> +	{ .compatible = "qcom,sdm845-qce", },
> +	{ .compatible = "qcom,sm8150-qce", },
> +	{ .compatible = "qcom,sm8250-qce", },
> +	{ .compatible = "qcom,sm8350-qce", },
> +	{ .compatible = "qcom,sm8450-qce", },
> +	{ .compatible = "qcom,sm8550-qce", },
I did not agree with this at v7 and I still do not agree. We already did
some effort to clean this pattern in other drivers, so to make it clear
- driver does not need 10 compatibles because they are the same. And
before anyone responds that we need SoC-specific compatibles, yes, we
need them, its is obvious, but in the bindings. Not in the driver.

Please go with SoC compatible fallback, as many times encouraged by Rob.
Worst case go with generic fallback compatible.

Best regards,
Krzysztof

Re: [PATCH v8 9/9] crypto: qce: core: Add new compatibles for qce crypto driver

[Vladimir Zapolskiy]

Hi Krzysztof,

On 2/2/23 16:01, Krzysztof Kozlowski wrote:
> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>
>> Since we decided to use soc specific compatibles for describing
>> the qce crypto IP nodes in the device-trees, adapt the driver
>> now to handle the same.
>>
>> Keep the old deprecated compatible strings still in the driver,
>> to ensure backward compatibility.
>>
>> Cc: Bjorn Andersson <andersson@kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: herbert@gondor.apana.org.au
>> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>> [vladimir: added more SoC specfic compatibles]
>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>> ---
>>   drivers/crypto/qce/core.c | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
>> index 8e496fb2d5e2..2420a5ff44d1 100644
>> --- a/drivers/crypto/qce/core.c
>> +++ b/drivers/crypto/qce/core.c
>> @@ -291,8 +291,20 @@ static int qce_crypto_remove(struct platform_device *pdev)
>>   }
>>   
>>   static const struct of_device_id qce_crypto_of_match[] = {
>> +	/* Following two entries are deprecated (kept only for backward compatibility) */
>>   	{ .compatible = "qcom,crypto-v5.1", },
>>   	{ .compatible = "qcom,crypto-v5.4", },
>> +	/* Add compatible strings as per updated dt-bindings, here: */
>> +	{ .compatible = "qcom,ipq4019-qce", },
>> +	{ .compatible = "qcom,ipq6018-qce", },
>> +	{ .compatible = "qcom,ipq8074-qce", },
>> +	{ .compatible = "qcom,msm8996-qce", },
>> +	{ .compatible = "qcom,sdm845-qce", },
>> +	{ .compatible = "qcom,sm8150-qce", },
>> +	{ .compatible = "qcom,sm8250-qce", },
>> +	{ .compatible = "qcom,sm8350-qce", },
>> +	{ .compatible = "qcom,sm8450-qce", },
>> +	{ .compatible = "qcom,sm8550-qce", },
> I did not agree with this at v7 and I still do not agree. We already did
> some effort to clean this pattern in other drivers, so to make it clear
> - driver does not need 10 compatibles because they are the same.

Here is a misunderstanding, the compatibles are not the same and it shall
not be assumed this way, only the current support of the IP on different SoCs
in the driver is the same.

Later on every minor found difference among IPs will require to break DTB ABI,
if all of the particular SoC specific comaptibles are not listed.

> And before anyone responds that we need SoC-specific compatibles, yes, we
> need them, its is obvious, but in the bindings. Not in the driver.
> 
> Please go with SoC compatible fallback, as many times encouraged by Rob.
> Worst case go with generic fallback compatible.
> 

--
Best wishes,
Vladimir

Re: [PATCH v8 9/9] crypto: qce: core: Add new compatibles for qce crypto driver

[Krzysztof Kozlowski]

On 02/02/2023 15:15, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
> 
> On 2/2/23 16:01, Krzysztof Kozlowski wrote:
>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>>
>>> Since we decided to use soc specific compatibles for describing
>>> the qce crypto IP nodes in the device-trees, adapt the driver
>>> now to handle the same.
>>>
>>> Keep the old deprecated compatible strings still in the driver,
>>> to ensure backward compatibility.
>>>
>>> Cc: Bjorn Andersson <andersson@kernel.org>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: herbert@gondor.apana.org.au
>>> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>> [vladimir: added more SoC specfic compatibles]
>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>> ---
>>>   drivers/crypto/qce/core.c | 12 ++++++++++++
>>>   1 file changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
>>> index 8e496fb2d5e2..2420a5ff44d1 100644
>>> --- a/drivers/crypto/qce/core.c
>>> +++ b/drivers/crypto/qce/core.c
>>> @@ -291,8 +291,20 @@ static int qce_crypto_remove(struct platform_device *pdev)
>>>   }
>>>   
>>>   static const struct of_device_id qce_crypto_of_match[] = {
>>> +	/* Following two entries are deprecated (kept only for backward compatibility) */
>>>   	{ .compatible = "qcom,crypto-v5.1", },
>>>   	{ .compatible = "qcom,crypto-v5.4", },
>>> +	/* Add compatible strings as per updated dt-bindings, here: */
>>> +	{ .compatible = "qcom,ipq4019-qce", },
>>> +	{ .compatible = "qcom,ipq6018-qce", },
>>> +	{ .compatible = "qcom,ipq8074-qce", },
>>> +	{ .compatible = "qcom,msm8996-qce", },
>>> +	{ .compatible = "qcom,sdm845-qce", },
>>> +	{ .compatible = "qcom,sm8150-qce", },
>>> +	{ .compatible = "qcom,sm8250-qce", },
>>> +	{ .compatible = "qcom,sm8350-qce", },
>>> +	{ .compatible = "qcom,sm8450-qce", },
>>> +	{ .compatible = "qcom,sm8550-qce", },
>> I did not agree with this at v7 and I still do not agree. We already did
>> some effort to clean this pattern in other drivers, so to make it clear
>> - driver does not need 10 compatibles because they are the same.
> 
> Here is a misunderstanding, the compatibles are not the same and it shall
> not be assumed this way, only the current support of the IP on different SoCs
> in the driver is the same.

They are the same for the driver. It's the same what we fixed for SDHCI
and other cases. Why this should be treated differently?

> 
> Later on every minor found difference among IPs will require to break DTB ABI,
> if all of the particular SoC specific comaptibles are not listed.

No, why? Why SDHCI and hundreds of other devices are not affected and
this one is?

Best regards,
Krzysztof

Re: [PATCH v8 9/9] crypto: qce: core: Add new compatibles for qce crypto driver

[Neil Armstrong]

On 02/02/2023 15:20, Krzysztof Kozlowski wrote:
> On 02/02/2023 15:15, Vladimir Zapolskiy wrote:
>> Hi Krzysztof,
>>
>> On 2/2/23 16:01, Krzysztof Kozlowski wrote:
>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>>>
>>>> Since we decided to use soc specific compatibles for describing
>>>> the qce crypto IP nodes in the device-trees, adapt the driver
>>>> now to handle the same.
>>>>
>>>> Keep the old deprecated compatible strings still in the driver,
>>>> to ensure backward compatibility.
>>>>
>>>> Cc: Bjorn Andersson <andersson@kernel.org>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: herbert@gondor.apana.org.au
>>>> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>>>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>>> [vladimir: added more SoC specfic compatibles]
>>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>>> ---
>>>>    drivers/crypto/qce/core.c | 12 ++++++++++++
>>>>    1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
>>>> index 8e496fb2d5e2..2420a5ff44d1 100644
>>>> --- a/drivers/crypto/qce/core.c
>>>> +++ b/drivers/crypto/qce/core.c
>>>> @@ -291,8 +291,20 @@ static int qce_crypto_remove(struct platform_device *pdev)
>>>>    }
>>>>    
>>>>    static const struct of_device_id qce_crypto_of_match[] = {
>>>> +	/* Following two entries are deprecated (kept only for backward compatibility) */
>>>>    	{ .compatible = "qcom,crypto-v5.1", },
>>>>    	{ .compatible = "qcom,crypto-v5.4", },
>>>> +	/* Add compatible strings as per updated dt-bindings, here: */
>>>> +	{ .compatible = "qcom,ipq4019-qce", },
>>>> +	{ .compatible = "qcom,ipq6018-qce", },
>>>> +	{ .compatible = "qcom,ipq8074-qce", },
>>>> +	{ .compatible = "qcom,msm8996-qce", },
>>>> +	{ .compatible = "qcom,sdm845-qce", },
>>>> +	{ .compatible = "qcom,sm8150-qce", },
>>>> +	{ .compatible = "qcom,sm8250-qce", },
>>>> +	{ .compatible = "qcom,sm8350-qce", },
>>>> +	{ .compatible = "qcom,sm8450-qce", },
>>>> +	{ .compatible = "qcom,sm8550-qce", },
>>> I did not agree with this at v7 and I still do not agree. We already did
>>> some effort to clean this pattern in other drivers, so to make it clear
>>> - driver does not need 10 compatibles because they are the same.
>>
>> Here is a misunderstanding, the compatibles are not the same and it shall
>> not be assumed this way, only the current support of the IP on different SoCs
>> in the driver is the same.

It seems the IP version is discoverable, in this case it's perfectly valid
to have a generic compatible along a soc specific compatible.

It has been done and validated multiple times, like for the ARM Mali Bifrost [1]

I'll propose then to add a generic "qcom,crypto" as fallback to
all of those new compatibles and clearly document that this is only
for crypto IP cores versions that have the runtime version discoverable.

We could even add a major version generic fallback compatible like "qcom,crypto-v5" or "qcom,crypto-v5.x"
to differentiate from older crypto devices.

Neil

> 
> They are the same for the driver. It's the same what we fixed for SDHCI
> and other cases. Why this should be treated differently?
> 
>>
>> Later on every minor found difference among IPs will require to break DTB ABI,
>> if all of the particular SoC specific comaptibles are not listed.
> 
> No, why? Why SDHCI and hundreds of other devices are not affected and
> this one is?
> 
> Best regards,
> Krzysztof
> 

[1] https://lore.kernel.org/all/20190401080949.14550-1-narmstrong@baylibre.com/

Re: [PATCH v8 9/9] crypto: qce: core: Add new compatibles for qce crypto driver

[Krzysztof Kozlowski]

On 03/02/2023 10:19, Neil Armstrong wrote:
> On 02/02/2023 15:20, Krzysztof Kozlowski wrote:
>> On 02/02/2023 15:15, Vladimir Zapolskiy wrote:
>>> Hi Krzysztof,
>>>
>>> On 2/2/23 16:01, Krzysztof Kozlowski wrote:
>>>> On 02/02/2023 14:50, Vladimir Zapolskiy wrote:
>>>>> From: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>>>>
>>>>> Since we decided to use soc specific compatibles for describing
>>>>> the qce crypto IP nodes in the device-trees, adapt the driver
>>>>> now to handle the same.
>>>>>
>>>>> Keep the old deprecated compatible strings still in the driver,
>>>>> to ensure backward compatibility.
>>>>>
>>>>> Cc: Bjorn Andersson <andersson@kernel.org>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Cc: herbert@gondor.apana.org.au
>>>>> Tested-by: Jordan Crouse <jorcrous@amazon.com>
>>>>> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
>>>>> [vladimir: added more SoC specfic compatibles]
>>>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>>>> ---
>>>>>    drivers/crypto/qce/core.c | 12 ++++++++++++
>>>>>    1 file changed, 12 insertions(+)
>>>>>
>>>>> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
>>>>> index 8e496fb2d5e2..2420a5ff44d1 100644
>>>>> --- a/drivers/crypto/qce/core.c
>>>>> +++ b/drivers/crypto/qce/core.c
>>>>> @@ -291,8 +291,20 @@ static int qce_crypto_remove(struct platform_device *pdev)
>>>>>    }
>>>>>    
>>>>>    static const struct of_device_id qce_crypto_of_match[] = {
>>>>> +	/* Following two entries are deprecated (kept only for backward compatibility) */
>>>>>    	{ .compatible = "qcom,crypto-v5.1", },
>>>>>    	{ .compatible = "qcom,crypto-v5.4", },
>>>>> +	/* Add compatible strings as per updated dt-bindings, here: */
>>>>> +	{ .compatible = "qcom,ipq4019-qce", },
>>>>> +	{ .compatible = "qcom,ipq6018-qce", },
>>>>> +	{ .compatible = "qcom,ipq8074-qce", },
>>>>> +	{ .compatible = "qcom,msm8996-qce", },
>>>>> +	{ .compatible = "qcom,sdm845-qce", },
>>>>> +	{ .compatible = "qcom,sm8150-qce", },
>>>>> +	{ .compatible = "qcom,sm8250-qce", },
>>>>> +	{ .compatible = "qcom,sm8350-qce", },
>>>>> +	{ .compatible = "qcom,sm8450-qce", },
>>>>> +	{ .compatible = "qcom,sm8550-qce", },
>>>> I did not agree with this at v7 and I still do not agree. We already did
>>>> some effort to clean this pattern in other drivers, so to make it clear
>>>> - driver does not need 10 compatibles because they are the same.
>>>
>>> Here is a misunderstanding, the compatibles are not the same and it shall
>>> not be assumed this way, only the current support of the IP on different SoCs
>>> in the driver is the same.
> 
> It seems the IP version is discoverable, in this case it's perfectly valid
> to have a generic compatible along a soc specific compatible.
> 
> It has been done and validated multiple times, like for the ARM Mali Bifrost [1]
> 
> I'll propose then to add a generic "qcom,crypto" as fallback to
> all of those new compatibles and clearly document that this is only
> for crypto IP cores versions that have the runtime version discoverable.

Yes, this is good idea.

> 
> We could even add a major version generic fallback compatible like "qcom,crypto-v5" or "qcom,crypto-v5.x"
> to differentiate from older crypto devices.

Since we have mapping of versions to SoC, it's also fine.


Best regards,
Krzysztof