Re: [PATCH v2 1/3] dt-bindings: crypto: qcom,ice: Add sa8255p support

[Linlin Zhang <linlin.zhang@oss.qualcomm.com>]

On 5/14/2026 8:55 PM, Krzysztof Kozlowski wrote:
> On Mon, May 11, 2026 at 08:37:48PM -0700, Linlin Zhang wrote:
>> On sa8255p, resources such as PHY, clocks, regulators, and resets are
>> managed by remote firmware via the SCMI power protocol. As a result, the
>> ICE driver cannot directly access clocks and must instead use power-domains
>> to request resource configuration.
> 
> Then how can it be compatible with qcom,inline-crypto-engine?

Thanks for the review.

You are right that the SCMI-based implementation differs from the
traditional inline crypto engine in terms of resource control. On
sa8255p, clocks and other resources are managed by remote firmware
via SCMI, so the driver does not directly control these resources
and instead relies on power domains.

Given this difference, the SCMI variant does not match the same
programming model as the existing qcom,inline-crypto-engine
implementation. Using it as a generic fallback is therefore not
appropriate, as the generic compatible implies that the device can
be handled equivalently by the same driver assumptions, which is
not the case here.

I will rework the bindings to:
  - introduce a separate binding for the SCMI-based variant, and
  - drop the generic fallback compatible string.

This should align better with other SCMI-based bindings and avoid
overloading the meaning of the generic compatible.

Thanks for pointing this out.

> 
>>
>> Add the qcom,sa8255p-inline-crypto-engine compatible string and make clocks
>> optional for platforms that use power-domains instead.
>>
>> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
>> ---
>>  .../crypto/qcom,inline-crypto-engine.yaml     | 27 ++++++++++++++++++-
>>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> So this is v2? But previous was v6? Look:
> 
> b4 diff '20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com'
> Looking up https://lore.kernel.org/all/20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com/
> Grabbing thread from lore.kernel.org/all/20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com/t.mbox.gz
> Checking for older revisions
> Grabbing search results from lore.kernel.org
> ---
> Analyzing 8 messages in the thread
> Could not find lower series to compare against.

This patch was review internally, and the final version was v6 which is
approved for posting to upstream review. I'm sorry that I forgot update
the version to v1 when I posted this patch to https://lore.kernel.org/.
This is why you see the previous was v6.

I updated the patch to v2 (this is current patchset) with some changes.

Would you please help instruct me how to fix it? need I re-post the patch
serial from v1?

> 
> 
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index 876bf90ed96e..4e7d9111d0eb 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> 
> This should go to its own binding file just like in all other
> SCMI-variant cases. And if you looked how these other files are done,
> you would see my complains already that generic fallback is most likely
> wrong.
> 
> Otherwise explain me what the generic fallback means here and how is it
> supposed to work?

ACK. I'll separate the binding and remove the generic fallback.

> 
> Best regards,
> Krzysztof
>