Message ID | 20231002180854.1603452-2-ben.wolsieffer@hefring.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1658498vqb; Mon, 2 Oct 2023 12:58:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFAyWlmOCItc7bq9qwTZX1JzUTPhn14Q6xfKrZBP80DhAzrSCPd8QarWw6wZi1v8+WBteB7 X-Received: by 2002:a05:6808:1a86:b0:3a9:efde:a022 with SMTP id bm6-20020a0568081a8600b003a9efdea022mr11083332oib.5.1696276717001; Mon, 02 Oct 2023 12:58:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696276716; cv=none; d=google.com; s=arc-20160816; b=sPRR/Joe4WSX+Qp7pQy1urKHoUNOMJO6szRKHzeJYNV1ntk77nIbXEi3jtLLfqL0dz 4a1RUWqcjWyFHxTgl5P+EtJw8CqGo2vAtLsR8cUhnsosMDZCi7jQOX9Dti2DMdVebzLR JFVOh3xdYe77pctHjiheTEV9R4O/rSKMO8sNYaQeJJCgMg6EefOpFrW1l1ubJSXjei7v FX5CpOZszFKOSW1Z2KxRYvjE5tcphlqsUhinyJxoZPhvPX9qtvKQ8FatXdJ3o2FLpswd aRTcvyM9LyRQ05vES24T42ne29mndnUP9xsVUmWFlDfGNpLOqCLNlBfbziXMPS7U1c6r VvmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=K/9udtHJxdUnIEfNuTeE6b1Yaqw4dJt+yBS5HPABR3I=; fh=kCIPcEqavua6BFvpW+ca31cFT8g0h238WggEKCCQPP0=; b=hOVCpBPylYdDnpU1MoUU/Y7QrKXDDdy7LODLrweuZa11tzSurIumqCrZRM/EV1U5LP WhxTFF/Ql/CxefW+p8AWZZG38hOY2Ryi+EOtx2MmZGta+lqnAi8YWQi5sloJRIXOWKyk vg83x1tZ4XCy1sMAV9F2BIgOFj/VFA6M2v07j0cFvWhB05AP+/pWEdXbpC4GUI5N0zH8 1+0mZhZhuYlMcRkVc0ixBtnJf/TICq+w2cUHsatNxtTwXHx3eEC0N37XPvklp/eiLySU f/ZjbElFUc20Wu5HBKUYye/DymgY74ZlcGmDmL9bVrHfDhz19nNMRqM6COdO0Ld+/s1D u0TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hefring-com.20230601.gappssmtp.com header.s=20230601 header.b=FXjpC1Bf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id lx14-20020a17090b4b0e00b00276df8c5b83si8951716pjb.143.2023.10.02.12.58.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 12:58:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@hefring-com.20230601.gappssmtp.com header.s=20230601 header.b=FXjpC1Bf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 8F17D826C4C4; Mon, 2 Oct 2023 11:09:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238760AbjJBSJg (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Mon, 2 Oct 2023 14:09:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238744AbjJBSJd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 2 Oct 2023 14:09:33 -0400 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6314C9 for <linux-kernel@vger.kernel.org>; Mon, 2 Oct 2023 11:09:30 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-774105e8c37so5614585a.3 for <linux-kernel@vger.kernel.org>; Mon, 02 Oct 2023 11:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hefring-com.20230601.gappssmtp.com; s=20230601; t=1696270170; x=1696874970; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=K/9udtHJxdUnIEfNuTeE6b1Yaqw4dJt+yBS5HPABR3I=; b=FXjpC1BfcbSAxOKwAOkJi1e5KiObsmqRyrZ1O755PF3BlijVsKtrR3kQOThxz/+a0k mVXmmmtNfc6ENPieANrBm/FwXLpuoi5mRikMgUENjRRlhiL43fcH+n7VWd+duBxzSCrj FKBb14j83CS2CamlUZBvccctthw1Aumqi1TEW2AyGYnuza60Qk2bzLWt3lIDmT8n7T3J ejMhEBkw/KrCOpdQmW4VVdx5xUpGKhOEFxsoufcQlzxlaqj9+P19GGQO0jEkXpc3UYgN E5Z+FXfq/OT/a1BkePzRvxfI9NZ7lJHqSiTv90gh7P1q/b9Q5PwtkYSqgYZMsVqDpBvd YAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696270170; x=1696874970; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K/9udtHJxdUnIEfNuTeE6b1Yaqw4dJt+yBS5HPABR3I=; b=Gx8Z/Qz0FpQkSy3upjSIC6eUD1ZVE1REQL3rxrTpgMmlgq0ZYB0XaoXZOaFLOgW46D t5IhFCyKICdv0P7ic+FP+42STNSlfVD+JtKfgkYda7/PueNQFzB2PGSSteNbkEd/bl3W ijNarNZoiRG2SkTLaV5FgH9qqjvAW+DTsaDfTy1ofRdTnvHL9uwXDhzIA2P8TN65CazM MKRbjWNArPUg0TtTbhdUsethdxnDJy05VdlldOREzCYI9/GE1QRjlZACIfqgQfEd0Y6S sXa8QuXlAA0ytY8Vq3+/EhlSQnEEvUCnWAoEk7KEiFvn6F+jtL1GwyGPHm+p+g/4fqf9 B58Q== X-Gm-Message-State: AOJu0Yy9Q1pnCFgC48M9nFmbGwjSLM77OVEKeKFZEbYW8puWcoMnBCf/ GtBqlOEHko5MN4BeI0lyIqFtmg== X-Received: by 2002:a05:620a:b5a:b0:770:9bd2:b3be with SMTP id x26-20020a05620a0b5a00b007709bd2b3bemr11139670qkg.5.1696270170028; Mon, 02 Oct 2023 11:09:30 -0700 (PDT) Received: from localhost.localdomain ([50.212.55.89]) by smtp.gmail.com with ESMTPSA id w15-20020ae9e50f000000b0077423f849c3sm7390255qkf.24.2023.10.02.11.09.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 11:09:29 -0700 (PDT) From: Ben Wolsieffer <ben.wolsieffer@hefring.com> To: linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Ben Wolsieffer <ben.wolsieffer@hefring.com> Subject: [PATCH 1/2] clk: stm32: initialize syscon after clocks are registered Date: Mon, 2 Oct 2023 14:08:53 -0400 Message-ID: <20231002180854.1603452-2-ben.wolsieffer@hefring.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231002180854.1603452-1-ben.wolsieffer@hefring.com> References: <20231002180854.1603452-1-ben.wolsieffer@hefring.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 02 Oct 2023 11:09:52 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778675054826580943 X-GMAIL-MSGID: 1778675054826580943 |
Series |
ARM: stm32: add clock for pwrcfg syscon
|
|
Commit Message
Ben Wolsieffer
Oct. 2, 2023, 6:08 p.m. UTC
The stm32-power-config syscon (PWR peripheral) is used in this driver
and the STM32 RTC driver to enable write access to backup domain
registers. The syscon's clock has a gate controlled by this clock
driver, but this clock is currently not registered in the device tree.
This only happens to work currently because all relevant clock setup and
RTC initialization happens before clk_disabled_unused(). After this
point, all syscon register writes are ignored.
If we simply add the syscon clock in the device tree, we end up with a
circular dependency because the clock has not been registered at the
point this driver requests the syscon.
This patch avoids this circular dependency by moving the syscon lookup
after the clocks are registered. This does appear to create a possible
race condition where someone could attempt to perform an operation on a
backup domain clock before the syscon has been initialized. This would
result in the operation having no effect because backup domain writes
could not be enabled. I'm not sure if this is a problem or if there is
a way to avoid it.
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
---
drivers/clk/clk-stm32f4.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Comments
Quoting Ben Wolsieffer (2023-10-02 11:08:53) > The stm32-power-config syscon (PWR peripheral) is used in this driver > and the STM32 RTC driver to enable write access to backup domain > registers. The syscon's clock has a gate controlled by this clock > driver, but this clock is currently not registered in the device tree. > This only happens to work currently because all relevant clock setup and > RTC initialization happens before clk_disabled_unused(). After this > point, all syscon register writes are ignored. Seems like we should mark those clks as CLK_IGNORE_UNUSED and add a comment to that fact. > > If we simply add the syscon clock in the device tree, we end up with a > circular dependency because the clock has not been registered at the > point this driver requests the syscon. > > This patch avoids this circular dependency by moving the syscon lookup > after the clocks are registered. This does appear to create a possible > race condition where someone could attempt to perform an operation on a > backup domain clock before the syscon has been initialized. This would > result in the operation having no effect because backup domain writes > could not be enabled. I'm not sure if this is a problem or if there is > a way to avoid it. There's no comment in the code that says the regmap must be set there instead of earlier. What's to stop someone from tripping over this problem later? At the least, please add a comment.
On Sun, Dec 17, 2023 at 03:05:01PM -0800, Stephen Boyd wrote: > Quoting Ben Wolsieffer (2023-10-02 11:08:53) > > The stm32-power-config syscon (PWR peripheral) is used in this driver > > and the STM32 RTC driver to enable write access to backup domain > > registers. The syscon's clock has a gate controlled by this clock > > driver, but this clock is currently not registered in the device tree. > > This only happens to work currently because all relevant clock setup and > > RTC initialization happens before clk_disabled_unused(). After this > > point, all syscon register writes are ignored. > > Seems like we should mark those clks as CLK_IGNORE_UNUSED and add a > comment to that fact. That seems like a worse solution than specifying the clock dependency in the device tree. > > > > > If we simply add the syscon clock in the device tree, we end up with a > > circular dependency because the clock has not been registered at the > > point this driver requests the syscon. > > > > This patch avoids this circular dependency by moving the syscon lookup > > after the clocks are registered. This does appear to create a possible > > race condition where someone could attempt to perform an operation on a > > backup domain clock before the syscon has been initialized. This would > > result in the operation having no effect because backup domain writes > > could not be enabled. I'm not sure if this is a problem or if there is > > a way to avoid it. > > There's no comment in the code that says the regmap must be set there > instead of earlier. What's to stop someone from tripping over this > problem later? At the least, please add a comment. Yeah, I'll fix that. Do you have any thoughts on the race condition I described? Should I add some kind of locking to block enable/disable_power_domain_write_protection() until stm32f4_rcc_init() attempts to initialize the syscon? Thank you, Ben
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c index 07c13ebe327d..a88e762d2b5e 100644 --- a/drivers/clk/clk-stm32f4.c +++ b/drivers/clk/clk-stm32f4.c @@ -1697,12 +1697,6 @@ static void __init stm32f4_rcc_init(struct device_node *np) return; } - pdrm = syscon_regmap_lookup_by_phandle(np, "st,syscfg"); - if (IS_ERR(pdrm)) { - pdrm = NULL; - pr_warn("%s: Unable to get syscfg\n", __func__); - } - match = of_match_node(stm32f4_of_match, np); if (WARN_ON(!match)) return; @@ -1894,6 +1888,12 @@ static void __init stm32f4_rcc_init(struct device_node *np) of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL); + pdrm = syscon_regmap_lookup_by_phandle(np, "st,syscfg"); + if (IS_ERR(pdrm)) { + pdrm = NULL; + pr_warn("%s: Unable to get syscfg\n", __func__); + } + return; fail: kfree(clks);