RCC is able to check the availability of a clock.
Allow to query the RCC with a firewall ID.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
index 88e52f10d1ec..4d471e3d89bc 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
@@ -31,6 +31,11 @@ properties:
   '#reset-cells':
     const: 1
 
+  '#access-controller-cells':
+    const: 1
+    description:
+      Contains the firewall ID associated to the peripheral.
+
   clocks:
     items:
       - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
@@ -123,6 +128,7 @@ required:
   - reg
   - '#clock-cells'
   - '#reset-cells'
+  - '#access-controller-cells'
   - clocks
 
 additionalProperties: false
@@ -136,6 +142,7 @@ examples:
         reg = <0x44200000 0x10000>;
         #clock-cells = <1>;
         #reset-cells = <1>;
+        #access-controller-cells = <1>;
         clocks =  <&scmi_clk CK_SCMI_HSE>,
                   <&scmi_clk CK_SCMI_HSI>,
                   <&scmi_clk CK_SCMI_MSI>,

-- 
2.43.0

On Fri, Jul 11, 2025 at 04:48:54PM +0200, Clément Le Goffic wrote:
> RCC is able to check the availability of a clock.
> Allow to query the RCC with a firewall ID.

If it is tied to a clock, do we need another provider? We have the 
"protected clocks" thing, but that might be a bit different.

> 
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
>  Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
> index 88e52f10d1ec..4d471e3d89bc 100644
> --- a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
> +++ b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
> @@ -31,6 +31,11 @@ properties:
>    '#reset-cells':
>      const: 1
>  
> +  '#access-controller-cells':
> +    const: 1
> +    description:
> +      Contains the firewall ID associated to the peripheral.
> +
>    clocks:
>      items:
>        - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
> @@ -123,6 +128,7 @@ required:
>    - reg
>    - '#clock-cells'
>    - '#reset-cells'
> +  - '#access-controller-cells'
>    - clocks
>  
>  additionalProperties: false
> @@ -136,6 +142,7 @@ examples:
>          reg = <0x44200000 0x10000>;
>          #clock-cells = <1>;
>          #reset-cells = <1>;
> +        #access-controller-cells = <1>;
>          clocks =  <&scmi_clk CK_SCMI_HSE>,
>                    <&scmi_clk CK_SCMI_HSI>,
>                    <&scmi_clk CK_SCMI_MSI>,
> 
> -- 
> 2.43.0
> 

Hi Rob,

On 7/15/25 05:17, Rob Herring wrote:
> On Fri, Jul 11, 2025 at 04:48:54PM +0200, Clément Le Goffic wrote:
>> RCC is able to check the availability of a clock.
>> Allow to query the RCC with a firewall ID.
> 
> If it is tied to a clock, do we need another provider? We have the
> "protected clocks" thing, but that might be a bit different.

What I understand is that the "protected-clocks" list is here to flag 
clocks as protected and the access to it and its register by the kernel 
may cause the reboot of the platform.
The current qcom implementation just drop clocks so no one can access to 
it after they are registered.
For my understanding if you know why the kernel needs the information 
"this clock can't be accessed", I would be interested/

Without the STM32 RCC driver modification, if we access to the DDRPERFM 
peripheral register when the clock is secured we face the same issue, we 
end up rebooting the platform.

Our RCC peripheral is able to know if our DDR subsystem clock (that is 
shared between our DDR controller and DDRPERFM peripheral) is secured or 
not, so we can access or not to DDRPERFM register.
It is the aim of the "access-controller" related code.

Correct me if I'm wrong but to me the difference might be that the 
"protected-clocks" property is here to list in the DT clocks that can't 
be accessed and that this information is not in the hardware.

In the STM32MP25 we are able to get this information through RCC 
dedicated register. You can look at the `stm32_rcc_get_access()` 
function in drivers/clk/stm32/clk-stm32mp25.c if needed.

Best regards,
Clément

Hello Rob,

On 7/15/25 05:17, Rob Herring wrote:
> On Fri, Jul 11, 2025 at 04:48:54PM +0200, Clément Le Goffic wrote:
>> RCC is able to check the availability of a clock.
>> Allow to query the RCC with a firewall ID.
> 
> If it is tied to a clock, do we need another provider? We have the
> "protected clocks" thing, but that might be a bit different.
> 

I couldn't find any reference to "protected-clocks" outside of qcom
related code, is there a documentation? (Couldn't find it in
clocks.yaml).

The RCC is firewall-aware and has it's own firewall configuration at
RCC level for some system resources. When checking access to a clock,
or a reset, we're reading RCC registers, hence declaring it as an
access-controller.

A RCC resource's firewall configuration usually covers more than a
clock.

>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>> ---
>>   Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
>> index 88e52f10d1ec..4d471e3d89bc 100644
>> --- a/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
>> +++ b/Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
>> @@ -31,6 +31,11 @@ properties:
>>     '#reset-cells':
>>       const: 1
>>   
>> +  '#access-controller-cells':
>> +    const: 1
>> +    description:
>> +      Contains the firewall ID associated to the peripheral.
>> +
>>     clocks:
>>       items:
>>         - description: CK_SCMI_HSE High Speed External oscillator (8 to 48 MHz)
>> @@ -123,6 +128,7 @@ required:
>>     - reg
>>     - '#clock-cells'
>>     - '#reset-cells'
>> +  - '#access-controller-cells'
>>     - clocks
>>   
>>   additionalProperties: false
>> @@ -136,6 +142,7 @@ examples:
>>           reg = <0x44200000 0x10000>;
>>           #clock-cells = <1>;
>>           #reset-cells = <1>;
>> +        #access-controller-cells = <1>;
>>           clocks =  <&scmi_clk CK_SCMI_HSE>,
>>                     <&scmi_clk CK_SCMI_HSI>,
>>                     <&scmi_clk CK_SCMI_MSI>,
>>
>> -- 
>> 2.43.0
>>

Best regards,
Gatien

On Tue, Jul 15, 2025 at 09:37:00AM +0200, Gatien CHEVALLIER wrote:
> Hello Rob,
> 
> On 7/15/25 05:17, Rob Herring wrote:
> > On Fri, Jul 11, 2025 at 04:48:54PM +0200, Clément Le Goffic wrote:
> > > RCC is able to check the availability of a clock.
> > > Allow to query the RCC with a firewall ID.
> > 
> > If it is tied to a clock, do we need another provider? We have the
> > "protected clocks" thing, but that might be a bit different.
> > 
> 
> I couldn't find any reference to "protected-clocks" outside of qcom
> related code, is there a documentation? (Couldn't find it in
> clocks.yaml).

Huh? protected-clocks is in clocks.yaml... It is there with an explanation.

Best regards,
Krzysztof

On 7/15/25 10:19, Krzysztof Kozlowski wrote:
> On Tue, Jul 15, 2025 at 09:37:00AM +0200, Gatien CHEVALLIER wrote:
>> Hello Rob,
>>
>> On 7/15/25 05:17, Rob Herring wrote:
>>> On Fri, Jul 11, 2025 at 04:48:54PM +0200, Clément Le Goffic wrote:
>>>> RCC is able to check the availability of a clock.
>>>> Allow to query the RCC with a firewall ID.
>>>
>>> If it is tied to a clock, do we need another provider? We have the
>>> "protected clocks" thing, but that might be a bit different.
>>>
>>
>> I couldn't find any reference to "protected-clocks" outside of qcom
>> related code, is there a documentation? (Couldn't find it in
>> clocks.yaml).
> 
> Huh? protected-clocks is in clocks.yaml... It is there with an explanation.
> 
> Best regards,
> Krzysztof
> 

Ah, I was looking at Rob's repo, my bad.