Update the inline-crypto engine DT binding to allow specifying up to two
clocks along with their names and associated power-domain. When the
'clk_ignore_unused' flag is not passed on the kernel command line
occasional unclocked ICE hardware register access are observed during ICE
driver probe based on the relative timing between the probe and the kernel
disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
flag is not passed on the command line, clock 'stuck' issues are
observed if the power-domain required by ICE hardware is unused and thus
disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
the associated power-domain should be specified in the ICE device tree node
and the 'iface' clock should be voted on by the ICE driver during probe.
Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
---
.../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index c3408dcf5d20..d9a0a8adf645 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -28,6 +28,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: ice_core_clk
+ - const: iface_clk
+
+ power-domains:
maxItems: 1
required:
@@ -45,6 +55,10 @@ examples:
compatible = "qcom,sm8550-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x01d88000 0x8000>;
- clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>;
+ clock-names = "ice_core_clk",
+ "iface_clk";
+ power-domains = <&gcc UFS_PHY_GDSC>;
};
...
--
2.34.1On 10/03/2026 09:06, Harshal Dev wrote:
> Update the inline-crypto engine DT binding to allow specifying up to two
> clocks along with their names and associated power-domain. When the
> 'clk_ignore_unused' flag is not passed on the kernel command line
> occasional unclocked ICE hardware register access are observed during ICE
> driver probe based on the relative timing between the probe and the kernel
> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
> flag is not passed on the command line, clock 'stuck' issues are
> observed if the power-domain required by ICE hardware is unused and thus
> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
> the associated power-domain should be specified in the ICE device tree node
> and the 'iface' clock should be voted on by the ICE driver during probe.
>
> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> index c3408dcf5d20..d9a0a8adf645 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> @@ -28,6 +28,16 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> + maxItems: 2
> +
> + clock-names:
> + minItems: 1
> + items:
> + - const: ice_core_clk
core
> + - const: iface_clk
iface or bus
I don't understand why this is flexible and commit msg does not explain
that. Devices do not have one and two clocks at the same time. You miss
proper constraints.
> +
> + power-domains:
> maxItems: 1
Best regards,
Krzysztof
On 3/11/2026 1:55 AM, Krzysztof Kozlowski wrote:
> On 10/03/2026 09:06, Harshal Dev wrote:
>> Update the inline-crypto engine DT binding to allow specifying up to two
>> clocks along with their names and associated power-domain. When the
>> 'clk_ignore_unused' flag is not passed on the kernel command line
>> occasional unclocked ICE hardware register access are observed during ICE
>> driver probe based on the relative timing between the probe and the kernel
>> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
>> flag is not passed on the command line, clock 'stuck' issues are
>> observed if the power-domain required by ICE hardware is unused and thus
>> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
>> the associated power-domain should be specified in the ICE device tree node
>> and the 'iface' clock should be voted on by the ICE driver during probe.
>>
>> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index c3408dcf5d20..d9a0a8adf645 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> @@ -28,6 +28,16 @@ properties:
>> maxItems: 1
>>
>> clocks:
>> + minItems: 1
>> + maxItems: 2
>> +
>> + clock-names:
>> + minItems: 1
>> + items:
>> + - const: ice_core_clk
>
> core
Ack. I'll introduce a check for this specific name here as well:
https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/soc/qcom/ice.c#L582
>
>> + - const: iface_clk
>
> iface or bus
Ack, will call it 'iface'.
>
> I don't understand why this is flexible and commit msg does not explain
> that. Devices do not have one and two clocks at the same time. You miss
> proper constraints.
>
I agree, it might confuse someone reading the commit message the first time.
I'll re-write the commit message to make it explicit that even though these
two properties are 'required', for the time being we are introducing 'iface'
clk and 'power-domain' as an optional property to maintain bisectability,
and that the properties would be made 'required' in a subsequent commit once
the DTS changes which are part of this patch series have reached the top tree.
Let me know if any concerns with this kind of commit message.
Regards,
Harshal
>> +
>> + power-domains:
>> maxItems: 1
>
>
> Best regards,
> Krzysztof
On 11/03/2026 10:37, Harshal Dev wrote:
>
>
> On 3/11/2026 1:55 AM, Krzysztof Kozlowski wrote:
>> On 10/03/2026 09:06, Harshal Dev wrote:
>>> Update the inline-crypto engine DT binding to allow specifying up to two
>>> clocks along with their names and associated power-domain. When the
>>> 'clk_ignore_unused' flag is not passed on the kernel command line
>>> occasional unclocked ICE hardware register access are observed during ICE
>>> driver probe based on the relative timing between the probe and the kernel
>>> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
>>> flag is not passed on the command line, clock 'stuck' issues are
>>> observed if the power-domain required by ICE hardware is unused and thus
>>> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
>>> the associated power-domain should be specified in the ICE device tree node
>>> and the 'iface' clock should be voted on by the ICE driver during probe.
>>>
>>> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>> ---
>>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
>>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>> index c3408dcf5d20..d9a0a8adf645 100644
>>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>> @@ -28,6 +28,16 @@ properties:
>>> maxItems: 1
>>>
>>> clocks:
>>> + minItems: 1
>>> + maxItems: 2
>>> +
>>> + clock-names:
>>> + minItems: 1
>>> + items:
>>> + - const: ice_core_clk
>>
>> core
>
> Ack. I'll introduce a check for this specific name here as well:
> https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/soc/qcom/ice.c#L582
>
>>
>>> + - const: iface_clk
>>
>> iface or bus
>
> Ack, will call it 'iface'.
>
>>
>> I don't understand why this is flexible and commit msg does not explain
>> that. Devices do not have one and two clocks at the same time. You miss
>> proper constraints.
>>
>
> I agree, it might confuse someone reading the commit message the first time.
> I'll re-write the commit message to make it explicit that even though these
> two properties are 'required', for the time being we are introducing 'iface'
> clk and 'power-domain' as an optional property to maintain bisectability,
> and that the properties would be made 'required' in a subsequent commit once
> the DTS changes which are part of this patch series have reached the top tree.
>
> Let me know if any concerns with this kind of commit message.
So you are adding it for backwards compatibility? It's fine then,
although I had impression you are fixing something which is not working
correctly. New devices will need to constrain this.
Best regards,
Krzysztof
On 11/03/2026 19:25, Krzysztof Kozlowski wrote:
> On 11/03/2026 10:37, Harshal Dev wrote:
>>
>>
>> On 3/11/2026 1:55 AM, Krzysztof Kozlowski wrote:
>>> On 10/03/2026 09:06, Harshal Dev wrote:
>>>> Update the inline-crypto engine DT binding to allow specifying up to two
>>>> clocks along with their names and associated power-domain. When the
>>>> 'clk_ignore_unused' flag is not passed on the kernel command line
>>>> occasional unclocked ICE hardware register access are observed during ICE
>>>> driver probe based on the relative timing between the probe and the kernel
>>>> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
>>>> flag is not passed on the command line, clock 'stuck' issues are
>>>> observed if the power-domain required by ICE hardware is unused and thus
>>>> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
>>>> the associated power-domain should be specified in the ICE device tree node
>>>> and the 'iface' clock should be voted on by the ICE driver during probe.
>>>>
>>>> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>> ---
>>>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
>>>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>>> index c3408dcf5d20..d9a0a8adf645 100644
>>>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>>> @@ -28,6 +28,16 @@ properties:
>>>> maxItems: 1
>>>>
>>>> clocks:
>>>> + minItems: 1
>>>> + maxItems: 2
>>>> +
>>>> + clock-names:
>>>> + minItems: 1
>>>> + items:
>>>> + - const: ice_core_clk
>>>
>>> core
>>
>> Ack. I'll introduce a check for this specific name here as well:
>> https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/soc/qcom/ice.c#L582
>>
>>>
>>>> + - const: iface_clk
>>>
>>> iface or bus
>>
>> Ack, will call it 'iface'.
>>
>>>
>>> I don't understand why this is flexible and commit msg does not explain
>>> that. Devices do not have one and two clocks at the same time. You miss
>>> proper constraints.
>>>
>>
>> I agree, it might confuse someone reading the commit message the first time.
>> I'll re-write the commit message to make it explicit that even though these
>> two properties are 'required', for the time being we are introducing 'iface'
>> clk and 'power-domain' as an optional property to maintain bisectability,
>> and that the properties would be made 'required' in a subsequent commit once
>> the DTS changes which are part of this patch series have reached the top tree.
>>
>> Let me know if any concerns with this kind of commit message.
>
> So you are adding it for backwards compatibility? It's fine then,
> although I had impression you are fixing something which is not working
> correctly. New devices will need to constrain this.
Except new devices, like Eliza and Milos. And then this should go to
current fixes.
Best regards,
Krzysztof
Hi Krzysztof,
On 3/11/2026 11:58 PM, Krzysztof Kozlowski wrote:
> On 11/03/2026 19:25, Krzysztof Kozlowski wrote:
>> On 11/03/2026 10:37, Harshal Dev wrote:
>>>
>>>
>>> On 3/11/2026 1:55 AM, Krzysztof Kozlowski wrote:
>>>> On 10/03/2026 09:06, Harshal Dev wrote:
>>>>> Update the inline-crypto engine DT binding to allow specifying up to two
>>>>> clocks along with their names and associated power-domain. When the
>>>>> 'clk_ignore_unused' flag is not passed on the kernel command line
>>>>> occasional unclocked ICE hardware register access are observed during ICE
>>>>> driver probe based on the relative timing between the probe and the kernel
>>>>> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
>>>>> flag is not passed on the command line, clock 'stuck' issues are
>>>>> observed if the power-domain required by ICE hardware is unused and thus
>>>>> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
>>>>> the associated power-domain should be specified in the ICE device tree node
>>>>> and the 'iface' clock should be voted on by the ICE driver during probe.
>>>>>
>>>>> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>> ---
>>>>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
>>>>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>>>> index c3408dcf5d20..d9a0a8adf645 100644
>>>>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>>>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>>>> @@ -28,6 +28,16 @@ properties:
>>>>> maxItems: 1
>>>>>
>>>>> clocks:
>>>>> + minItems: 1
>>>>> + maxItems: 2
>>>>> +
>>>>> + clock-names:
>>>>> + minItems: 1
>>>>> + items:
>>>>> + - const: ice_core_clk
>>>>
>>>> core
>>>
>>> Ack. I'll introduce a check for this specific name here as well:
>>> https://elixir.bootlin.com/linux/v7.0-rc3/source/drivers/soc/qcom/ice.c#L582
>>>
>>>>
>>>>> + - const: iface_clk
>>>>
>>>> iface or bus
>>>
>>> Ack, will call it 'iface'.
>>>
>>>>
>>>> I don't understand why this is flexible and commit msg does not explain
>>>> that. Devices do not have one and two clocks at the same time. You miss
>>>> proper constraints.
>>>>
>>>
>>> I agree, it might confuse someone reading the commit message the first time.
>>> I'll re-write the commit message to make it explicit that even though these
>>> two properties are 'required', for the time being we are introducing 'iface'
>>> clk and 'power-domain' as an optional property to maintain bisectability,
>>> and that the properties would be made 'required' in a subsequent commit once
>>> the DTS changes which are part of this patch series have reached the top tree.
>>>
>>> Let me know if any concerns with this kind of commit message.
>>
>> So you are adding it for backwards compatibility? It's fine then,
>> although I had impression you are fixing something which is not working
>> correctly. New devices will need to constrain this.
>
Yes, this is for backward compatibility.
> Except new devices, like Eliza and Milos. And then this should go to
> current fixes.
I'm not sure if I understand correctly, do you mean to say that except for Eliza
and Milos, new devices need to change their DT binding to 'required' with
corresponding DTS changes. And then, the patch updating the DT binding also needs
to be back-ported?
I'm assuming you're leaving out Eliza and Milos because they aren't supported
on the stable branches yet?
Apologies in advance if you meant something else and I have completely misunderstood
your comment.
Regards,
Harshal
>
> Best regards,
> Krzysztof
On 13/03/2026 12:45, Harshal Dev wrote: >> Except new devices, like Eliza and Milos. And then this should go to >> current fixes. > > I'm not sure if I understand correctly, do you mean to say that except for Eliza > and Milos, new devices need to change their DT binding to 'required' with > corresponding DTS changes. And then, the patch updating the DT binding also needs > to be back-ported? No. All new devices must require this. You only preserve released ABI, so fix unreleased ABI (Eliza and Milos) now, before it gets released. Best regards, Krzysztof
Hello Krzysztof, On 3/13/2026 9:28 PM, Krzysztof Kozlowski wrote: > On 13/03/2026 12:45, Harshal Dev wrote: >>> Except new devices, like Eliza and Milos. And then this should go to >>> current fixes. >> >> I'm not sure if I understand correctly, do you mean to say that except for Eliza >> and Milos, new devices need to change their DT binding to 'required' with >> corresponding DTS changes. And then, the patch updating the DT binding also needs >> to be back-ported? > > No. All new devices must require this. You only preserve released ABI, > so fix unreleased ABI (Eliza and Milos) now, before it gets released. > I'm already being annoying, but I will disturb you one more time for clarification. :) By saying 'fix unreleased ABI now' do you mean to say that I should add another trailing commit at the end of this patch series which marks these resources as 'required' in the DT-binding without carrying the 'Fixes' tag? Specifically so that Eliza and Milos carry this constrain. From what I understood from Bjorn's comment, the DTS and ICE driver sources will reach from different trees and either could be merged first. To maintain bisectability we should first merge this patch series followed by a subsequent patch which marks these resources as 'required' in the DT-binding along with accompanying ICE driver source changes which fail probe when 'iface' clk isn't available. Of course, the subsequent patch will not be back-ported as a fix. Many thanks for your time, Harshal > Best regards, > Krzysztof
On 16/03/2026 11:56, Harshal Dev wrote: > Hello Krzysztof, > > On 3/13/2026 9:28 PM, Krzysztof Kozlowski wrote: >> On 13/03/2026 12:45, Harshal Dev wrote: >>>> Except new devices, like Eliza and Milos. And then this should go to >>>> current fixes. >>> >>> I'm not sure if I understand correctly, do you mean to say that except for Eliza >>> and Milos, new devices need to change their DT binding to 'required' with >>> corresponding DTS changes. And then, the patch updating the DT binding also needs >>> to be back-ported? >> >> No. All new devices must require this. You only preserve released ABI, >> so fix unreleased ABI (Eliza and Milos) now, before it gets released. >> > > I'm already being annoying, but I will disturb you one more time for clarification. :) > > By saying 'fix unreleased ABI now' do you mean to say that I should add another > trailing commit at the end of this patch series which marks these resources as > 'required' in the DT-binding without carrying the 'Fixes' tag? Specifically so that > Eliza and Milos carry this constrain. Please post a v3 of this patch for crypto subsystem, doing what you did here plus requiring these clocks for Eliza and Milos, with explanation why this is a fix thus why this should go to current cycle. > > From what I understood from Bjorn's comment, the DTS and ICE driver sources will reach > from different trees and either could be merged first. To maintain bisectability we They are applied to different trees. Period. This defines everything, you cannot fix it post factum, you cannot fix bisectability afterwards. > should first merge this patch series followed by a subsequent patch which marks these > resources as 'required' in the DT-binding along with accompanying ICE driver source Then you have a released ABI and you cannot change it, so what does this achieve? Just look what is merged where and you will see the differences. I don't see Milos crypto engine in current cycle, do you? And bisectability has nothing to do here. You need to fix ABI before it gets released. > changes which fail probe when 'iface' clk isn't available. Of course, the subsequent > patch will not be back-ported as a fix. Best regards, Krzysztof
Hi Krzysztof, On 3/16/2026 4:39 PM, Krzysztof Kozlowski wrote: > On 16/03/2026 11:56, Harshal Dev wrote: >> Hello Krzysztof, >> >> On 3/13/2026 9:28 PM, Krzysztof Kozlowski wrote: >>> On 13/03/2026 12:45, Harshal Dev wrote: >>>>> Except new devices, like Eliza and Milos. And then this should go to >>>>> current fixes. >>>> >>>> I'm not sure if I understand correctly, do you mean to say that except for Eliza >>>> and Milos, new devices need to change their DT binding to 'required' with >>>> corresponding DTS changes. And then, the patch updating the DT binding also needs >>>> to be back-ported? >>> >>> No. All new devices must require this. You only preserve released ABI, >>> so fix unreleased ABI (Eliza and Milos) now, before it gets released. >>> >> >> I'm already being annoying, but I will disturb you one more time for clarification. :) >> >> By saying 'fix unreleased ABI now' do you mean to say that I should add another >> trailing commit at the end of this patch series which marks these resources as >> 'required' in the DT-binding without carrying the 'Fixes' tag? Specifically so that >> Eliza and Milos carry this constrain. > > Please post a v3 of this patch for crypto subsystem, doing what you did > here plus requiring these clocks for Eliza and Milos, with explanation > why this is a fix thus why this should go to current cycle. > Got it now, I will add additional bindings which make the clock and power-domain mandatory for Eliza (unreleased ABI) while keeping them optional for others (released ABI). But I feel I should add this as a separate commit which carries a Fixes tag for this: https://lore.kernel.org/all/20260223-eliza-bindings-crypto-ice-v1-1-fc76c1a5adce@oss.qualcomm.com/ This commit with it's current Fixes tag is required to be back-ported on LTS branches because they fail to boot for LeMans and Kodiak. Let me know if that's not good, and I should add the additional binding in the same commit. > >> >> From what I understood from Bjorn's comment, the DTS and ICE driver sources will reach >> from different trees and either could be merged first. To maintain bisectability we > > > They are applied to different trees. Period. This defines everything, > you cannot fix it post factum, you cannot fix bisectability afterwards. Ack. > >> should first merge this patch series followed by a subsequent patch which marks these >> resources as 'required' in the DT-binding along with accompanying ICE driver source > > Then you have a released ABI and you cannot change it, so what does this > achieve? Ack. > > Just look what is merged where and you will see the differences. I don't > see Milos crypto engine in current cycle, do you? I don't either. I believe only Eliza has been added till now, I'll re-base and add only for Eliza right now. Subsequent patches for Milos will know where the entry needs to be added. > > And bisectability has nothing to do here. You need to fix ABI before it > gets released. Got it. Thanks! Regards, Harshal > >> changes which fail probe when 'iface' clk isn't available. Of course, the subsequent >> patch will not be back-ported as a fix. > > > > > Best regards, > Krzysztof
On 3/10/26 9:06 AM, Harshal Dev wrote:
> Update the inline-crypto engine DT binding to allow specifying up to two
> clocks along with their names and associated power-domain. When the
> 'clk_ignore_unused' flag is not passed on the kernel command line
> occasional unclocked ICE hardware register access are observed during ICE
> driver probe based on the relative timing between the probe and the kernel
> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
> flag is not passed on the command line, clock 'stuck' issues are
> observed if the power-domain required by ICE hardware is unused and thus
> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
> the associated power-domain should be specified in the ICE device tree node
> and the 'iface' clock should be voted on by the ICE driver during probe.
>
> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> index c3408dcf5d20..d9a0a8adf645 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> @@ -28,6 +28,16 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> + maxItems: 2
> +
> + clock-names:
> + minItems: 1
> + items:
> + - const: ice_core_clk
> + - const: iface_clk
Trim the "_clk", we know they're clocks, because they come under.. you
know.. the 'clocks' property! :D
Konrad
On 3/10/2026 7:43 PM, Konrad Dybcio wrote:
> On 3/10/26 9:06 AM, Harshal Dev wrote:
>> Update the inline-crypto engine DT binding to allow specifying up to two
>> clocks along with their names and associated power-domain. When the
>> 'clk_ignore_unused' flag is not passed on the kernel command line
>> occasional unclocked ICE hardware register access are observed during ICE
>> driver probe based on the relative timing between the probe and the kernel
>> disabling the unused clocks. On the other hand, when the 'pd_ignore_unused'
>> flag is not passed on the command line, clock 'stuck' issues are
>> observed if the power-domain required by ICE hardware is unused and thus
>> disabled before ICE probe. To avoid these scenarios, the 'iface' clock and
>> the associated power-domain should be specified in the ICE device tree node
>> and the 'iface' clock should be voted on by the ICE driver during probe.
>>
>> Fixes: f6ff91a47ac57 ("dt-bindings: crypto: Add Qualcomm Inline Crypto Engine")
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index c3408dcf5d20..d9a0a8adf645 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> @@ -28,6 +28,16 @@ properties:
>> maxItems: 1
>>
>> clocks:
>> + minItems: 1
>> + maxItems: 2
>> +
>> + clock-names:
>> + minItems: 1
>> + items:
>> + - const: ice_core_clk
>> + - const: iface_clk
>
> Trim the "_clk", we know they're clocks, because they come under.. you
> know.. the 'clocks' property! :D
>
Ack.
Regards,
Harshal
> Konrad
© 2016 - 2026 Red Hat, Inc.