Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp2570299rdd; Fri, 12 Jan 2024 14:00:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IH2g4whYWc5Hb5UbRuTLe5TfJwmlrwlItFR8RwIcKjqx3tnO0aplm2H8W/l2IAy5UtHnnJT X-Received: by 2002:a05:6358:50c9:b0:170:e2dc:3e19 with SMTP id m9-20020a05635850c900b00170e2dc3e19mr3394598rwm.43.1705096819098; Fri, 12 Jan 2024 14:00:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705096819; cv=none; d=google.com; s=arc-20160816; b=e3+nR0FuUK6ciyRrFcfHqh4escGfTkzQ9FDrTxhkULkJjneYX1kMDm47KNMpxaJU7z xrjHMzPP4tgC1lsTGloWot8T9bh8Fg+PX+s2hCYKRYNQoUd3k+Ig+xwO49r+xvJDrQT0 aOD9lfQM+OPUH48daRsvqHTqaBvCUtQ42IYyUYTlto8hO3Ro7qewKwHZwS4XmpA9+VYe k8q+tvB9PWOEtOsDl+YBRp2CZND9O3gAclpOh3/3ViSE3zR69uefNEBWVUbTyNBM1ntO s34ktsrpcCALa49eXv+f22RHMklU8mph5q/iEm1iGk/0WQyBIkquOj50N0SABVoZiLw7 VSUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=0hhVOcFdh1HTKD3eGnDrrPjtYobkiYS23JtQg/2eggU=; fh=rCUH7xE2Gjed8ApFIC0ORvnhlCbAbXnJg0MAYCEDDSk=; b=i4u0q5FiuykP+yZX4boECtw/GaD5rlmDNJDS8sK/NdCnfYlneVMaNWLuHji3IM59x1 fM9Z+1CH2h5NMRPbiwzV0LOY/7ZPN17BdIoPYIQzQ3CjLTn8ANg23d4P8tJuYuZ1vPJ8 GojzYLa2Cdi5+oa+VLuKRtyBXosERK/KhYyOMs+E2JpzHXFQ4giWbhNTbgWoqc+VjGOZ BD4GOIDIQ8piwZl5uhtwLYaez/zs/Mmm08Bs66nhl3jW81BJcd7ZTmvvoW0zK1Av6hDm YNmCRlnYL231sOjeNrcfw7CCSve9dBPvRWUcS7x5yl+Rjlkslt1zsEwujMzMageiYOsI KTKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hefring-com.20230601.gappssmtp.com header.s=20230601 header.b=MltP2E0w; spf=pass (google.com: domain of linux-kernel+bounces-25053-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25053-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id c14-20020a170902d48e00b001d3e6debb8dsi4640874plg.373.2024.01.12.14.00.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 14:00:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25053-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@hefring-com.20230601.gappssmtp.com header.s=20230601 header.b=MltP2E0w; spf=pass (google.com: domain of linux-kernel+bounces-25053-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25053-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 5EEBE286567 for ; Fri, 12 Jan 2024 22:00:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B406B17730; Fri, 12 Jan 2024 22:00:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=hefring-com.20230601.gappssmtp.com header.i=@hefring-com.20230601.gappssmtp.com header.b="MltP2E0w" Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C96717725 for ; Fri, 12 Jan 2024 22:00:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=hefring.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=hefring.com Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-dbe69afb431so6171771276.1 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=vger.kernel.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=MltP2E0wHB66G1e+RUw5daU0x9C0fvyB/NMYNtcbhGnKt8aVHsw42ZckMLOY1BuYJj +r5Qm+NR0EaqihUhhPyT2e/3TX8VCQbZCwybMBl3chpeMqFxRv5LuU3yJdCPVSYy21WV BqRVNXl2JU3ctNwuFBUauDJI2jHmrfwxqG8z37ytKYtFuLWGYvr5bXRrRndaJWJG1uHU xUIBxby97F96nIvreeC4v/NRo1eyIyzanJjx/CP9f4+aeyDJupqbSlFfYuJqVBwm+Z/o dHk3VNmGpu7ipTQCU9RTRkouOtBzWX4GUGgZEz1TNrnj/vc3YgLlqiZvGD++lH1YP+5R 7WmA== 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=NsDAtZMmXp5dNSXzbuTLKE1G9ENiHxFEu/W/ZEto84GksuKOpeqEGEDh/eDj8UuQ93 BRloyTe/+JHBrvcQyj/l0WNsaWUir2URYWYkZWrxCj9PavX+YpzZgB+iGCqOuBjChcrz L8CkjgUHB6NHy4hV6TySMtcTth+VGoSkc2boxEqfQjEjwBNnSBTxy9Xl+WHd84PRywNk UrOHEw5xE5xXAXtokut6H8fTefOD4vKVA0og8cqNajDll6zox+oqc6GE532bpPwNzzWZ 0xOnXZTZnSe1foIopy+l/l/VmmK32KmcVcSy7h0WWkKH3FXxuEv/Fx7iygSX34CqhJbv /hmQ== X-Gm-Message-State: AOJu0Yz9AAbGYFomiKeWILF80a45zG8Qwolh4pxSb/q1m07wqa425IS1 bZC9pTBR+BBuHkNZYpbCAA6QJLEQoJ3xpQ== 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <883a61872f94c972cc410da84eaf7b97.sboyd@kernel.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