From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 673C72F8EA0 for ; Thu, 25 Jun 2026 11:38:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782387531; cv=none; b=iQGp2Xwx2EbhPieZBgQ0aXvfdurjBYO3EM5Urpn1GEfoPb1/EYSSEveuN2TwYRQFBnLgWH+OHzYpI15aonTG2m4zMYxlur6UkmLfaBuIn7N1CTcuQvmH3vuhWR1LQiJkAzWHptde7C/3gHi8D7uZ/2lCuOkVaScw/jqU8IQLfPY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782387531; c=relaxed/simple; bh=dNJMKE8Fb6m6nRBSQf7lQCMZOJCugTd17FFgofP/eds=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aymxIORDBFeAKiNQgkM8IyV1nqt7XRz4Gq+oRYWbw4CXrTCHe840wIGzEb7YIlFukwqTyK+5OCMuRh/9c0VoWOoiOi4iMYX2+TkjSLhK8t5PRDdOaElC0aQV5U0k9+6pWnFut69PTu3LAlePYiVs2XN/T3b9GyASvrTO3nNjh2s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=RjCN4L1J; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=lAMpmWeQ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="RjCN4L1J"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="lAMpmWeQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782387528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Eb+j6jBjdeQpLj6vYhJ/GQkkOLBPXDRRMzcQgZKL2uc=; b=RjCN4L1JsQPysHyFEVfer7mMqpPSLNe6UMmafcbShizq6Ec3stFghcv349WXrBtoswjlWq 8qRIj6lSvUMTliNJ9rYziZLi0GGO09VjOjTqmfPRhBigKwzBEEXv0WRrB5j7hjJPO8x4kB ySjcjJ2JCHJOpJe+oATuptPhqtSnMxs= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-592-Q5XRKF5DP3GmozVx3HzN5A-1; Thu, 25 Jun 2026 07:38:47 -0400 X-MC-Unique: Q5XRKF5DP3GmozVx3HzN5A-1 X-Mimecast-MFC-AGG-ID: Q5XRKF5DP3GmozVx3HzN5A_1782387527 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-519899aa6bfso32652581cf.1 for ; Thu, 25 Jun 2026 04:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782387527; x=1782992327; darn=vger.kernel.org; h=user-agent: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=Eb+j6jBjdeQpLj6vYhJ/GQkkOLBPXDRRMzcQgZKL2uc=; b=lAMpmWeQZ6Olu6/1NZoydzaFcTQFKWh7PoUSZcH4erPrnRWhCnzTrUb4abYuFrOVaK t3+q7mZnxcl4FSzaHmrhgE+FQ4jZ0KyvqVfNFFLhRfdJ1P8YhlJ4fh/I+nA9UuH+Zf2Z N6T4K2369UXgUc2DwfiYg84GBVNgtFdIS25JRzbx7bvP20w12mGOOaX2TcVrSFWKlRar p53clSWiTM/T2fO3hfYtmGCdZ2QA16dfoPQHylMdSDqgchXpPbAyfFokwjej/EW4Al+9 TjDEnEu4GeWvsAR2TmqL7GmbjK+OsqtkmjyFLfQOwjPo65Zp6yN2WBZMEwYnknqKbDnI FQMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782387527; x=1782992327; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Eb+j6jBjdeQpLj6vYhJ/GQkkOLBPXDRRMzcQgZKL2uc=; b=Qss+ZSLF4FBADB+AMRkqXdSxWQ8mg/uAwF+GJugdQdxN3NywMWYm1PRQrSJgCsWiAo OVHWq080WXXHOLvFy338a2xpcT/gOeWQkJFIlXqFI8E5VP7Eo8X16K4f0xL+ulUzZCJy rTb0kDt9N7N1vfdY7Mn4ES/t74jhqZq3aOmv1cooS0eaL3ImqCNet1gzrd3Cqj80R81c J1qv5MqFzRVN34IRrnJkn6j9zwNms8UBNtIa0HaRZIxX8ul6KNEy2IWtodz1YXftj/VX mFq2G8EQ/rxhHh/oXqr9WjTklDV5LldlfU3nIDQw/Akm0WL3lVDsybWws3a3tqWiokgJ Vc5Q== X-Forwarded-Encrypted: i=1; AFNElJ8Dy/IYfWrvEVK4Ta1GpvsTNAJUdh8XZyn+ABW10tW3tIixXQkmijeTTWzPOkpj7BL5gMKPchy446O3Wlo=@vger.kernel.org X-Gm-Message-State: AOJu0Yyz9S+ETiYzjnosRuJ2lVoiPuBXzFGfUlSGXZT9OysRIJWCNPnM ZEblJTZl/3ESIdBzPzon77588T3PYCD5XSiGilOi5laVLqxfWNiWNMvSVGWWfkWvlOGfnciTjV4 6b4MuJ2bCLvI5wPDZXBjV0M8vMXrNgA4vU03judkc6t2sB9DiJCEm5ObpgIDcNa5krQ== X-Gm-Gg: AfdE7cnEEyCezOUepUe7Eu3h2Rt7WS3t8RDGLhKOs2B09NSDcJSAHq82AaaU1i3QYPA XH6JCNFuC7ayOwM81VinRVBeJQbhAZTQR0v6FDMsUtUQFpS7bYN38L5sX/iZPli17hSvbEBjCdh Gx+DXVBvJc9ID43zfX300xLa9eCwo9hQweMFWKfY9uOwrfg3IvdQE3FO+zU8BHrny4zJqpzBOUR jtH0vd2dJB1WQjg/ZaQXoQ0kpY9EDpSvsxn+LeuifE2JNlDGNcfq3qPFqjRTsQp1Ksyxdk4haSd ReKMoyVrlPdhlIDGRFXzzzGPH7+RsfNjGewcQIxLOeLjhPbiFV3jsNA3NpTpWGmAoMy0GDkz7an Jc2ZgcuSFYCgZGJw5EKrmB4LDl+q2CX/g00SLdNlK01fMQw== X-Received: by 2002:ac8:7dcd:0:b0:51a:1128:4b3e with SMTP id d75a77b69052e-51a7283a782mr28783581cf.29.1782387526723; Thu, 25 Jun 2026 04:38:46 -0700 (PDT) X-Received: by 2002:ac8:7dcd:0:b0:51a:1128:4b3e with SMTP id d75a77b69052e-51a7283a782mr28783101cf.29.1782387526090; Thu, 25 Jun 2026 04:38:46 -0700 (PDT) Received: from redhat.com (c-73-183-53-213.hsd1.pa.comcast.net. [73.183.53.213]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51a51a9bca9sm69288951cf.19.2026.06.25.04.38.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2026 04:38:44 -0700 (PDT) Date: Thu, 25 Jun 2026 07:38:42 -0400 From: Brian Masney To: Konrad Dybcio Cc: Saravana Kannan , Abel Vesa , Maxime Ripard , Michael Turquette , Stephen Boyd , Russell King , Bjorn Andersson , Hans de Goede , Dmitry Baryshkov , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Jens Glathe Subject: Re: [PATCH v2 2/5] clk: qcom: common: introduce qcom_cc_sync_state() Message-ID: References: <20260616-clk-sync-state-v2-0-15f82c64d95c@redhat.com> <20260616-clk-sync-state-v2-2-15f82c64d95c@redhat.com> <21bbffb7-ce99-4c38-a5cc-6a3f3c7f48eb@oss.qualcomm.com> 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: <21bbffb7-ce99-4c38-a5cc-6a3f3c7f48eb@oss.qualcomm.com> User-Agent: Mutt/2.3.2 (2026-04-26) Hi Konrad, On Thu, Jun 25, 2026 at 11:44:12AM +0200, Konrad Dybcio wrote: > On 6/16/26 11:09 PM, Brian Masney wrote: > > Several qcom clk providers currently have a sync_state helper set to > > icc_sync_state(). With an upcoming change to the clk framework, if > > sync_state is not defined for the device, then the clk framework sets it > > to clk_sync_state(). > > > > Clk providers that require their own sync_state will need to call the > > framework level clk_sync_state(). Let's introduce a new common helper > > qcom_cc_sync_state() that calls icc_sync_state() and clk_sync_state(). > > > > Tested-by: Jens Glathe > > Signed-off-by: Brian Masney > > --- > > drivers/clk/qcom/common.c | 9 +++++++++ > > drivers/clk/qcom/common.h | 1 + > > 2 files changed, 10 insertions(+) > > > > diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c > > index eec369d2173b..31382c49c948 100644 > > --- a/drivers/clk/qcom/common.c > > +++ b/drivers/clk/qcom/common.c > > @@ -3,12 +3,14 @@ > > * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. > > */ > > > > +#include > > #include > > #include > > #include > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -464,5 +466,12 @@ int qcom_cc_probe_by_index(struct platform_device *pdev, int index, > > } > > EXPORT_SYMBOL_GPL(qcom_cc_probe_by_index); > > > > +void qcom_cc_sync_state(struct device *dev) > > +{ > > + icc_sync_state(dev); > > As mentioned before, we really need to test for (qcom_cc_desc)->icc_hws > here > > If icc_sync_state() is called without an interconnect provider > being registered, the framework state gets messed up: > > --- drivers/interconnect/core.c > void icc_sync_state(struct device *dev) > { > struct icc_provider *p; > struct icc_node *n; > static int count; // function-static variable > > count++; // called for every clock controller in this revision > > if (count < providers_count) // kaboom > return; > > // actual sync_state never happens anymore > > Presumably one would pass this through drvdata, but be careful as > some drivers use it for other purposes today My next version of this series that I haven't posted yet allows chaining the sync_state callbacks at the driver core level. It doesn't require any of the QC clk driver changes, and will allow us to play nicely with the pmdomain subsystem, and any others the move to sync_state in the future. I think I see the confusion between us the last few rounds of review. In this series, I added qcom_cc_sync_state() and converted 6 drivers over to use it. (I excluded clk-cbf-8996.c since it is separate.) Only the 6 drivers today that called icc_sync_state() now call qcom_cc_sync_state() -> icc_sync_state(). So from my vantage point it is the same overall functionality. I didn't look at this from the perspective of qcom_cc_sync_state() would be common infrastructure, and a newly added driver in the future that may not interact with the ICC framework may use this. Is this correct? I asked earlier if this was an existing bug, and the response was no. Once I fix my x13s today, and able to verify my v3 sync_state still works as expected, I'll post the new version. Brian