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
