From: Clement LE GOFFIC <clement.legoffic@foss.st.com>
To: Rob Herring <robh@kernel.org>
Cc: Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Jonathan Corbet <corbet@lwn.net>,
Gatien Chevallier <gatien.chevallier@foss.st.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Gabriel Fernandez <gabriel.fernandez@foss.st.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Le Goffic <legoffic.clement@gmail.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-perf-users@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<linux-clk@vger.kernel.org>
Subject: Re: [PATCH v2 02/16] dt-bindings: stm32: stm32mp25: add `access-controller-cell` property
Date: Tue, 15 Jul 2025 13:47:38 +0200 [thread overview]
Message-ID: <cfeaa4b0-6894-4363-ba43-25eee31ed497@foss.st.com> (raw)
In-Reply-To: <20250715031717.GA4144523-robh@kernel.org>
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
next prev parent reply other threads:[~2025-07-15 11:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 14:48 [PATCH v2 00/16] Introduce STM32 DDR PMU for STM32MP platforms Clément Le Goffic
2025-07-11 14:48 ` [PATCH v2 01/16] bus: firewall: move stm32_firewall header file in include folder Clément Le Goffic
2025-07-11 14:48 ` [PATCH v2 02/16] dt-bindings: stm32: stm32mp25: add `access-controller-cell` property Clément Le Goffic
2025-07-15 3:17 ` Rob Herring
2025-07-15 7:37 ` Gatien CHEVALLIER
2025-07-15 8:19 ` Krzysztof Kozlowski
2025-07-15 8:40 ` Gatien CHEVALLIER
2025-07-15 11:47 ` Clement LE GOFFIC [this message]
2025-07-11 14:48 ` [PATCH v2 03/16] clk: stm32mp25: add firewall grant_access ops Clément Le Goffic
2025-07-11 14:48 ` [PATCH v2 04/16] arm64: dts: st: set rcc as an access-controller Clément Le Goffic
2025-07-11 14:48 ` [PATCH v2 05/16] dt-bindings: memory: add jedec,ddr[3-4]-channel binding Clément Le Goffic
2025-07-21 20:09 ` Rob Herring
2025-07-22 7:35 ` Clement LE GOFFIC
2025-07-11 14:48 ` [PATCH v2 06/16] arm64: dts: st: add LPDDR channel to stm32mp257f-dk board Clément Le Goffic
2025-07-15 3:20 ` Rob Herring
2025-07-15 8:32 ` Clement LE GOFFIC
2025-07-15 15:02 ` Rob Herring
2025-07-21 15:44 ` Clement LE GOFFIC
2025-07-11 14:48 ` [PATCH v2 07/16] arm64: dts: st: add DDR channel to stm32mp257f-ev1 board Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 08/16] dt-bindings: perf: stm32: introduce DDRPERFM dt-bindings Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 09/16] perf: stm32: introduce DDRPERFM driver Clément Le Goffic
2025-07-11 16:04 ` Jonathan Cameron
2025-07-15 9:49 ` Clement LE GOFFIC
2025-07-14 19:39 ` Dan Carpenter
2025-07-11 14:49 ` [PATCH v2 10/16] Documentation: perf: stm32: add ddrperfm support Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 11/16] MAINTAINERS: add myself as STM32 DDR PMU maintainer Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 12/16] ARM: dts: stm32: add ddrperfm on stm32mp131 Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 13/16] ARM: dts: stm32: add ddrperfm on stm32mp151 Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 14/16] arm64: dts: st: add ddrperfm on stm32mp251 Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 15/16] arm64: dts: st: support ddrperfm on stm32mp257f-dk Clément Le Goffic
2025-07-11 14:49 ` [PATCH v2 16/16] arm64: dts: st: support ddrperfm on stm32mp257f-ev1 Clément Le Goffic
2025-07-14 15:24 ` [PATCH v2 00/16] Introduce STM32 DDR PMU for STM32MP platforms Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cfeaa4b0-6894-4363-ba43-25eee31ed497@foss.st.com \
--to=clement.legoffic@foss.st.com \
--cc=alexandre.torgue@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=gabriel.fernandez@foss.st.com \
--cc=gatien.chevallier@foss.st.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=legoffic.clement@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mark.rutland@arm.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).