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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>

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@xxxxxxxxxx>
Cc: Rob Herring <robh@xxxxxxxxxx>
Cc: herbert@xxxxxxxxxxxxxxxxxxx
Tested-by: Jordan Crouse <jorcrous@xxxxxxxxxx>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@xxxxxxxxxx>
[vladimir: added more SoC specfic compatibles]
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@xxxxxxxxxx>
---
   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@xxxxxxxxxxxx/



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux