From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F27F2C4707C for ; Fri, 12 Jan 2024 22:00:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lB0rzlYPdjRP7j3dXOWt+obXcJ/aR2BsEHpD5crElqM=; b=iDjpPLG+DsjjR9 ZDmK7CKH+Ky/Dm1D2zUe+8uHtVYShyyI5Tr8rNb95cAGCH7PrbZY7YFbJsgxk8ZlR2P+bXFDS+qh5 UrsxkKuJk1ouUzFShhy5+5sZUGiUmh/tigE44BJZ5mJ/+zkOnyTtzBuJGlkbUXi8OJ/kQnoLsPNLl E8l2kg/vnAmr2xs+2VHqq3OIvzKqwuqpLHjDgw+3Ey6EZTAOEWB5qefNYlgCPK+1FWkuQqW7/Nzxw CyQu6QPhYqAd5eepwhuKseo6rNcC5FuWIXGTRhm0JXpFlEL6cevu4gq1lQ8Ihdk+qVEKYB1+WbtiJ zH5W96TW6n2dSy2EYRyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rOPZV-0044lo-0C; Fri, 12 Jan 2024 22:00:13 +0000 Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rOPZR-0044l7-2O for linux-arm-kernel@lists.infradead.org; Fri, 12 Jan 2024 22:00:11 +0000 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-5e7bb1e0db8so63126617b3.0 for ; Fri, 12 Jan 2024 14:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hefring-com.20230601.gappssmtp.com; s=20230601; t=1705096807; x=1705701607; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0hhVOcFdh1HTKD3eGnDrrPjtYobkiYS23JtQg/2eggU=; b=hMRYdrwkYwV9fd4VL6l1YXufKXl0IYhMgdJVrPXv2rhFcHhZIArDAuMjd8rVFsmkBi AYiGRhMiuWQxdNhkx34uSof7dpd+gPTYbyKtkpLTutE/g0q07pm+om4Yc7b1hGqO8bkz dGK9w7J6OnlGmwaAN69EFk/zvT2yWtuvhB9E84FB/tqWbQ/y6K4ACJF3svrr3wbzjE6B ijBXb10sHBssc7MdIH8ntc/00AW0Np+BsbFzmFgm4pDfLRfALECupvu05nBp0MjKjrMl 6tSHo/XLw8hOERsxyn9Na91HWW0Fbd2uCQFCB9nDRLxRWnD4G7AZwKHn+m+E3ueDBZ4F A0Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705096807; x=1705701607; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0hhVOcFdh1HTKD3eGnDrrPjtYobkiYS23JtQg/2eggU=; b=jlHAHSOlJ2psfUKFBmULCvX8Dp1dBNKmoF+QXYnJneWRmScB0Ia1Fax9T+fI2hn+XE xWrP4e9n+ua/nSqRpcwzrxRyy5JYzFJqB7rGU6QuZcdmDnUGFcoDeWLJe0RWOe8vciB5 jxyDAtJ4aCV5V42DdAQLB1hym0x7qQiRHJ9fHcO1H4SW77acRA4CJYWY4IXVt6IIJ5hi lPHblxVgKgugmxR0G18jnjKV/MRCA7IvjWAf70mPq/7VX6TP/UCqxZMvjytTZRPYu1dQ KLuZbrKjlH2qgk/0C+qrHDxkiRVP5oE6KT4f4aA9o3hEoovZdCrx4Gphz8h/7Y+dDlKU Rd6g== X-Gm-Message-State: AOJu0YwSGXMccvVzAIr3gzk25BT5w8y0gG8tt0zK6vR3czmLpkwJJFq/ 639Tci1ov5ywwEuKPIkvHWvsCd9kyv6h9g== X-Google-Smtp-Source: AGHT+IHbrYRi12cOjI23zBiUfiGMMjgGZ1WdMjYT+UYdd79zzlNQgTtNbGfGpkVNdrhDuqR5cHrh/g== X-Received: by 2002:a05:6902:2182:b0:dbd:5be1:1768 with SMTP id dl2-20020a056902218200b00dbd5be11768mr1339723ybb.73.1705096807499; Fri, 12 Jan 2024 14:00:07 -0800 (PST) Received: from dell-precision-5540 ([50.212.55.90]) by smtp.gmail.com with ESMTPSA id en12-20020a05622a540c00b00427e36e21d9sm1688262qtb.64.2024.01.12.14.00.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 14:00:06 -0800 (PST) Date: Fri, 12 Jan 2024 17:00:04 -0500 From: Ben Wolsieffer To: Stephen Boyd Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Maxime Coquelin , Alexandre Torgue , Michael Turquette Subject: Re: [PATCH 1/2] clk: stm32: initialize syscon after clocks are registered Message-ID: References: <20231002180854.1603452-1-ben.wolsieffer@hefring.com> <20231002180854.1603452-2-ben.wolsieffer@hefring.com> <883a61872f94c972cc410da84eaf7b97.sboyd@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <883a61872f94c972cc410da84eaf7b97.sboyd@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240112_140010_020145_B79F1828 X-CRM114-Status: GOOD ( 31.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel