mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Corentin Labbe" <clabbe@baylibre.com>,
	davem@davemloft.net, herbert@gondor.apana.org.au,
	krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com,
	p.zabel@pengutronix.de, robh+dt@kernel.org, sboyd@kernel.org,
	ricardo@pardini.net, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 5/6] reset: rockchip: secure reset must be used by SCMI
Date: Sat, 11 Nov 2023 22:28:59 +0100	[thread overview]
Message-ID: <4f86c7da-5589-4451-89cb-739b97b67170@linaro.org> (raw)
In-Reply-To: <20231111205115.6hkhjj37ypeq45ax@mercury.elektranox.org>

On 11/11/2023 21:51, Sebastian Reichel wrote:
> Hi,
> 
> On Tue, Nov 07, 2023 at 06:45:03PM +0100, Krzysztof Kozlowski wrote:
>> On 07/11/2023 18:35, Heiko Stübner wrote:
>>> Am Dienstag, 7. November 2023, 17:21:41 CET schrieb Krzysztof Kozlowski:
>>>> On 07/11/2023 16:55, Corentin Labbe wrote:
>>>>> While working on the rk3588 crypto driver, I loose lot of time
>>>>> understanding why resetting the IP failed.
>>>>> This is due to RK3588_SECURECRU_RESET_OFFSET being in the secure world,
>>>>> so impossible to operate on it from the kernel.
>>>>> All resets in this block must be handled via SCMI call.
>>>>>
>>>>> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
>>>>> ---
>>>>>  drivers/clk/rockchip/rst-rk3588.c             | 42 ------------
>>>>>  .../dt-bindings/reset/rockchip,rk3588-cru.h   | 68 +++++++++----------
>>>>
>>>> Please run scripts/checkpatch.pl and fix reported warnings. Some
>>>> warnings can be ignored, but the code here looks like it needs a fix.
>>>> Feel free to get in touch if the warning is not clear.
>>>>
>>>>>  2 files changed, 34 insertions(+), 76 deletions(-)
>>>>>
>>>>> diff --git a/drivers/clk/rockchip/rst-rk3588.c b/drivers/clk/rockchip/rst-rk3588.c
>>>>> index e855bb8d5413..6556d9d3c7ab 100644
>>>>> --- a/drivers/clk/rockchip/rst-rk3588.c
>>>>> +++ b/drivers/clk/rockchip/rst-rk3588.c
>>>>> @@ -16,9 +16,6 @@
>>>>>  /* 0xFD7C8000 + 0x0A00 */
>>>>>  #define RK3588_PHPTOPCRU_RESET_OFFSET(id, reg, bit) [id] = (0x8000*4 + reg * 16 + bit)
>>>>>  
>>>>> -/* 0xFD7D0000 + 0x0A00 */
>>>>> -#define RK3588_SECURECRU_RESET_OFFSET(id, reg, bit) [id] = (0x10000*4 + reg * 16 + bit)
>>>>> -
>>>>>  /* 0xFD7F0000 + 0x0A00 */
>>>>>  #define RK3588_PMU1CRU_RESET_OFFSET(id, reg, bit) [id] = (0x30000*4 + reg * 16 + bit)
>>>>>  
>>>>> @@ -806,45 +803,6 @@ static const int rk3588_register_offset[] = {
>>>>>  	RK3588_PMU1CRU_RESET_OFFSET(SRST_P_PMU0IOC, 5, 4),
>>>>>  	RK3588_PMU1CRU_RESET_OFFSET(SRST_P_GPIO0, 5, 5),
>>>>>  	RK3588_PMU1CRU_RESET_OFFSET(SRST_GPIO0, 5, 6),
>>>>> -
>>>>> -	/* SECURECRU_SOFTRST_CON00 */
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_A_SECURE_NS_BIU, 0, 10),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_SECURE_NS_BIU, 0, 11),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_A_SECURE_S_BIU, 0, 12),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_SECURE_S_BIU, 0, 13),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_P_SECURE_S_BIU, 0, 14),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_CRYPTO_CORE, 0, 15),
>>>>> -
>>>>> -	/* SECURECRU_SOFTRST_CON01 */
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_CRYPTO_PKA, 1, 0),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_CRYPTO_RNG, 1, 1),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_A_CRYPTO, 1, 2),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_CRYPTO, 1, 3),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_KEYLADDER_CORE, 1, 9),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_KEYLADDER_RNG, 1, 10),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_A_KEYLADDER, 1, 11),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_KEYLADDER, 1, 12),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_P_OTPC_S, 1, 13),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_OTPC_S, 1, 14),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_WDT_S, 1, 15),
>>>>> -
>>>>> -	/* SECURECRU_SOFTRST_CON02 */
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_T_WDT_S, 2, 0),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_BOOTROM, 2, 1),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_A_DCF, 2, 2),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_P_DCF, 2, 3),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_BOOTROM_NS, 2, 5),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_P_KEYLADDER, 2, 14),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_TRNG_S, 2, 15),
>>>>> -
>>>>> -	/* SECURECRU_SOFTRST_CON03 */
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_TRNG_NS, 3, 0),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_D_SDMMC_BUFFER, 3, 1),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_SDMMC, 3, 2),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_H_SDMMC_BUFFER, 3, 3),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_SDMMC, 3, 4),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_P_TRNG_CHK, 3, 5),
>>>>> -	RK3588_SECURECRU_RESET_OFFSET(SRST_TRNG_S, 3, 6),
>>>>>  };
>>>>>  
>>>>>  void rk3588_rst_init(struct device_node *np, void __iomem *reg_base)
>>>>> diff --git a/include/dt-bindings/reset/rockchip,rk3588-cru.h b/include/dt-bindings/reset/rockchip,rk3588-cru.h
>>>>> index d4264db2a07f..c0d08ae78cd5 100644
>>>>> --- a/include/dt-bindings/reset/rockchip,rk3588-cru.h
>>>>> +++ b/include/dt-bindings/reset/rockchip,rk3588-cru.h
>>>>> @@ -716,39 +716,39 @@
>>>>>  #define SRST_P_GPIO0			627
>>>>>  #define SRST_GPIO0			628
>>>>>  
>>>>> -#define SRST_A_SECURE_NS_BIU		629
>>>>> -#define SRST_H_SECURE_NS_BIU		630
>>>>> -#define SRST_A_SECURE_S_BIU		631
>>>>> -#define SRST_H_SECURE_S_BIU		632
>>>>> -#define SRST_P_SECURE_S_BIU		633
>>>>> -#define SRST_CRYPTO_CORE		634
>>>>> -
>>>>> -#define SRST_CRYPTO_PKA			635
>>>>> -#define SRST_CRYPTO_RNG			636
>>>>> -#define SRST_A_CRYPTO			637
>>>>> -#define SRST_H_CRYPTO			638
>>>>> -#define SRST_KEYLADDER_CORE		639
>>>>> -#define SRST_KEYLADDER_RNG		640
>>>>> -#define SRST_A_KEYLADDER		641
>>>>> -#define SRST_H_KEYLADDER		642
>>>>> -#define SRST_P_OTPC_S			643
>>>>> -#define SRST_OTPC_S			644
>>>>> -#define SRST_WDT_S			645
>>>>> -
>>>>> -#define SRST_T_WDT_S			646
>>>>> -#define SRST_H_BOOTROM			647
>>>>> -#define SRST_A_DCF			648
>>>>> -#define SRST_P_DCF			649
>>>>> -#define SRST_H_BOOTROM_NS		650
>>>>> -#define SRST_P_KEYLADDER		651
>>>>> -#define SRST_H_TRNG_S			652
>>>>> -
>>>>> -#define SRST_H_TRNG_NS			653
>>>>> -#define SRST_D_SDMMC_BUFFER		654
>>>>> -#define SRST_H_SDMMC			655
>>>>> -#define SRST_H_SDMMC_BUFFER		656
>>>>> -#define SRST_SDMMC			657
>>>>> -#define SRST_P_TRNG_CHK			658
>>>>> -#define SRST_TRNG_S			659
>>>>> +#define SRST_A_SECURE_NS_BIU		10
>>>>
>>>> NAK. You just broke all users.
>>>
>>> If I'm reading the commit message correctly, all resets in that area
>>> couldn't have any users to begin with, as the registers controlling them
>>> are in the secure space, and need a higher exception level
>>>
>>> So if  anything is trying to handle these resets, would end up with some
>>> security exception right now.
>>>
>>> Though I guess we might want to use different names and not reuse the
>>> existing ones. scmi clocks use a SCMI_CLK_* id scheme, so maybe SCMI_SRST_* ?
>>
>> I don't quite get what the patch wants to achieve. Why dropping driver
>> support for given reset ID is connected with changing the value of
>> binding for given reset?
>>
>> What is the point of this define SRST_A_SECURE_NS_BIU 10?
> 
> This is about two different reset controllers. The IDs defined here
> are used by the operating system to access the correct registers.
> The kernel has a LUT from the ID to a register addresses, which is
> something you asked for during upstreaming.
> 
> The ID defined by Corentin is for reset control via SCMI firmware,
> which has different number scheme than Linux. To me the suggestion
> from Heiko looks sensible (i.e. create a new ID scheme and keep the
> current one unchanged).

So the binding is not for Linux but for FW? This should be explained in
the commit msg.

Best regards,
Krzysztof


  reply	other threads:[~2023-11-11 21:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07 15:55 [PATCH 0/6] crypto: rockchip: add support for rk3588/rk3568 Corentin Labbe
2023-11-07 15:55 ` [PATCH 1/6] dt-bindings: crypto: add support for rockchip,crypto-rk3588 Corentin Labbe
2023-11-07 16:40   ` Krzysztof Kozlowski
2023-11-20 12:37     ` Corentin LABBE
2023-11-21  9:04       ` Krzysztof Kozlowski
2023-11-07 15:55 ` [PATCH 2/6] MAINTAINERS: add new dt-binding doc to the right entry Corentin Labbe
2023-11-07 16:20   ` Krzysztof Kozlowski
2023-11-20 12:37     ` Corentin LABBE
2023-11-07 15:55 ` [PATCH 3/6] ARM64: dts: rk3588: add crypto node Corentin Labbe
2023-11-07 15:59   ` Heiko Stübner
2023-11-20 12:38     ` Corentin LABBE
2023-11-07 16:20   ` Krzysztof Kozlowski
2023-11-20 12:38     ` Corentin LABBE
2023-11-07 15:55 ` [PATCH 4/6] ARM64: dts: rk356x: " Corentin Labbe
2023-11-07 16:00   ` Heiko Stübner
2023-11-07 16:21   ` Krzysztof Kozlowski
2023-11-07 15:55 ` [PATCH 5/6] reset: rockchip: secure reset must be used by SCMI Corentin Labbe
2023-11-07 16:21   ` Krzysztof Kozlowski
2023-11-07 17:35     ` Heiko Stübner
2023-11-07 17:45       ` Krzysztof Kozlowski
2023-11-11 20:51         ` Sebastian Reichel
2023-11-11 21:28           ` Krzysztof Kozlowski [this message]
2023-11-12 20:26             ` Sebastian Reichel
2023-11-20 12:42               ` Corentin LABBE
2023-11-07 15:55 ` [PATCH 6/6] crypto: rockchip: add rk3588 driver Corentin Labbe
2023-11-07 16:35   ` Krzysztof Kozlowski
2023-11-07 16:42     ` Krzysztof Kozlowski
2023-11-07 16:56       ` Krzysztof Kozlowski
2023-11-12 14:04   ` Aw: " Frank Wunderlich
2023-11-20 12:48     ` Corentin LABBE
2023-11-24 15:05       ` Aw: " Frank Wunderlich
2023-11-27 11:47         ` Corentin LABBE

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=4f86c7da-5589-4451-89cb-739b97b67170@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=clabbe@baylibre.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=ricardo@pardini.net \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    /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

all inboxes | Powered by JetHome®