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.129.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 0ECCC286D60 for ; Tue, 17 Mar 2026 22:09:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773785383; cv=none; b=loOxbVhWGJhTWSCMqlFCj5F4E2OmTMye8XtS1h2nRSsMja7+/QLF/Qb0EPxPmvKMsL8dbv2SSukCIPwgEPcaG6vP6BN8TVZvjHC5Mx4udrVMEprnx2522jcxcuqQjxlx7VJEyD+F2jpiFXwuTl3mHBd4JVwcY42ZonOow+dmmi0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773785383; c=relaxed/simple; bh=9X7swX/8yMUMhwMxtLNwij2a5oD3GT+erMjqq8TCDBE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FhbIZLsO0lftO+1TLmPPMUwtQqpCZuQ5FIcdAyp8p1MCRHll2ZsrDbWcdsfhJv1Td+hGW9021V94evkBx1y8P30V3H5X+xGP4ScBip74Q3X2VydTg1h2Q48DgSEXeIsiol5Zat8MZK6OWNRkEMS1UOHLS13wLlVDwT7ioLs3Vjc= 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=A04Vly5E; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=mrRLq07X; arc=none smtp.client-ip=170.10.129.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="A04Vly5E"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="mrRLq07X" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773785381; 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=dk1wudd/iOGrTdVOp9IBIbtc0x1PPisYVtUAogdFG9s=; b=A04Vly5EPe7Zfzatp1Gu6h4RYO681VRdqvjLTm6vRlxjIKzp/sZnw4GweFB7dO+S9vLgu9 7zR5sdLG0JcQKpniEfkaZLJvN4fWhKhfNnQtnzU3rZvttiRtcxDCbbRSSjZDND0qF3DeJm KetgUJNhV7CvgwOmgqv+mA5Sx5iaz90= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-437-3B0jBQ0eNuKR1GzQv1O4OA-1; Tue, 17 Mar 2026 18:09:39 -0400 X-MC-Unique: 3B0jBQ0eNuKR1GzQv1O4OA-1 X-Mimecast-MFC-AGG-ID: 3B0jBQ0eNuKR1GzQv1O4OA_1773785379 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-8cd7de0e161so4146099885a.2 for ; Tue, 17 Mar 2026 15:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1773785379; x=1774390179; 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=dk1wudd/iOGrTdVOp9IBIbtc0x1PPisYVtUAogdFG9s=; b=mrRLq07XCubdYoRJ/pDmZTKc3hxFE43WbOT3YBUwPR0MUA/o0mjeqTnkcxogrhFjfH gB78oOXm4vrrxVb6BJohmRRR0QI+82LWCxWO/4jav+U3Ff9oQ3KFoh5VLvPaU9Du/4Tj zBI09UiWwq2zDmpOMrGc3LWpVwfrHD+QuZkqQA1npRYPH8LQiJpkBCIonL8NKSRBSzuN ufi4kEPWq5mC+68NmWdM0IygY1MdtUg2E8xeGEM6hSm1NHjFsLhn5GlboYu6leBtKZrj dwHIdXUBNJT2smGai6b2tJEoylLTX8KgI9+gEU6PugizOOLyjaK18I7ZJ0IfPe9FFLzz 6C1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773785379; x=1774390179; 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=dk1wudd/iOGrTdVOp9IBIbtc0x1PPisYVtUAogdFG9s=; b=d3Ge6T+V/6QLgez88ulVJA3cc0QRFC2BCXjimafEapLVomjFmelHU5AvASXLnBmmes VANg3omIpBCSeDPcjcu7nZyamKrxTWs6Lu6O8EyesEVy6WEgZk6wIx1ECZ9QSDNd23hI lVNzBpux1y45Rtd5OJHb/uxe6K5HzfUoFndR1hTwMKdSUFTnRTuY4o5GBfLMeb1MI9sP 5vQ98B56hMjR0Lc8RRrh31fGLTY3G8usiMr35tTVIMQ7wNppTFv2iMXr4G3Me10MT9Vo i0O5lwsuVAGIf6kNmsyx63qO3htFJIk/WaR/Jl3H5MSJNTRrsewGnu/8H+oe5IpPrIOJ +vOQ== X-Forwarded-Encrypted: i=1; AJvYcCUfR/t6lW6c9X9885bir9vM5hMydgRSdbZkJfrbWUb7t4tNY1+/npgb3CQq0kAGwli/qVxwrtbYbau5VQY=@vger.kernel.org X-Gm-Message-State: AOJu0YxaPLEy6pYf4v+ydWUoz8T43R/ZSqF8fpBPuntSABZaiUMbiUul K0Oam7JaqiPm1KT/wOeOk206CM+wTUMfoqCEHxfFtqE3WYUSh9FXKw3sRAwQD+yHGBaarNaOfYh bOj+DsiD9IooSh5oKq/MFLBPCl1AzZfZub9mzTmsYE9T/RGsIGj2IjUOT6Z1ngBgpD+nVI4XQcw == X-Gm-Gg: ATEYQzwGW4cfeMPk1NUbkmnxfFU2gZAa1h/UsJhCoFwCQEa8l28JHORl9ME8zex801Q jnqT7Q1j97CE0Ja1UvpGBVsWyRi0l5vpORB35LGmstr4Z4MIGlNPA1S3XzgYJL9ZBvKXaZMy+04 2Cbyh+ZU8DRDL5ivRiT7ojQNj+VEtLjNc/rgxaFw/vk7xg1/2XrIyFKrKgKg1B9HwVR51GGHTkT jmMaw7y06Hl9B642kMP+nphfP2UQUWwYLKHuUe9DElGVUdb00GZaMVcdx++bU3sPtEWFcxjf/gt qMHClMTIE85Dj50u+/pdBJYbDEs5Pt9VvMu9kYnjZgvrMi/aF/7qT1Djsbl4gzBJjMLCOrDIgrd F9sMrfGrzUJqmHf76ua901aOU4BEOsWRHwUie0z2ydgb8yDadvvWYUfii X-Received: by 2002:a05:620a:4488:b0:8ca:123e:819c with SMTP id af79cd13be357-8cfad2f5edfmr177071485a.35.1773785379015; Tue, 17 Mar 2026 15:09:39 -0700 (PDT) X-Received: by 2002:a05:620a:4488:b0:8ca:123e:819c with SMTP id af79cd13be357-8cfad2f5edfmr177068185a.35.1773785378579; Tue, 17 Mar 2026 15:09:38 -0700 (PDT) Received: from redhat.com (c-73-183-52-120.hsd1.pa.comcast.net. [73.183.52.120]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cfacdb21bbsm74143685a.2.2026.03.17.15.09.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 15:09:38 -0700 (PDT) Date: Tue, 17 Mar 2026 18:09:36 -0400 From: Brian Masney To: Christian Marangi Cc: Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] clk: add clk_hw_recalc_rate() to trigger HW clk rate recalculation Message-ID: References: <20260317173255.5531-1-ansuelsmth@gmail.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: <20260317173255.5531-1-ansuelsmth@gmail.com> User-Agent: Mutt/2.3.0 (2026-01-25) Hi Christian, On Tue, Mar 17, 2026 at 06:32:45PM +0100, Christian Marangi wrote: > There is currently a latent problem with HW clk that only expose a > .recalc_rate OP and doesn't have a .set_rate() and also have the > CLK_GET_RATE_NOCACHE flag set. In such case the rate in clk core is > parsed only (and set) only at init and when the full clk_set_rate() > is called. In every other case .recalc_rate() is never called. As you pointed out below, it's also called for the full clk_get_rate(). > > It's also possible that an HW clk of this type, initially report 0 as rate > as the register are still not configured and the HW clk effectively doesn't > return any rate. > > This gets especially problematic when a clock provider use such clk as a > parent and require the rate for parent selection for the final rate > calculation. > > In such case, since the HW clk rate is never updated after init, it's still > 0 and cause problems with any other HW clk that use .determine_rate() or > .round_rate() and search for the closest rate using clk_hw_get_rate() on > the parents. > > This doesn't happen if the full clk_get_rate() is used instead as it will > check if CLK_GET_RATE_NOCACHE is set and recalculate the rate accordingly. > > Updating the clk_hw_get_rate() to align to what clk_get_rate() does is not > possible as it should be lockless and might cause problems in any user of > clk_hw_get_rate(). > > A more safe approach is the introduction of a direct function that triggers > the HW clk rate recalculation, clk_hw_recalc_rate(). > > Any driver that implement an HW clk that entirely depends on some register > to configure the rate (that are externally configured) and have only > .recalc_rate() and set CLK_GET_RATE_NOCACHE (aka the case where the HW clk > rate actually change and depends on the external register configuration) > will have to call clk_hw_recalc_rate() on the HW clk after changing the > register configuration to sync the CCF with the new rate for the HW clk. > > Example: > > - All register zero -> HW clk rate = 0 > - PCS configure USXGMII mode -> HW clk rate = 0 > - PCS call clk_hw_recalc_rate() -> HW clk rate = 312MHz > - Port goes UP > - PCS/MAC scale the PHY port clock correctly by having > the correct reference clock as parent (instead of 0) > > Signed-off-by: Christian Marangi > --- > drivers/clk/clk.c | 23 +++++++++++++++++++++++ > include/linux/clk-provider.h | 1 + > 2 files changed, 24 insertions(+) > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > index 47093cda9df3..35e0cf627c24 100644 > --- a/drivers/clk/clk.c > +++ b/drivers/clk/clk.c > @@ -1977,6 +1977,29 @@ static unsigned long clk_core_get_rate_recalc(struct clk_core *core) > return clk_core_get_rate_nolock(core); > } > > +/** > + * clk_hw_recalc_rate - trigger rate recalculation for clk_hw > + * @hw: clk_hw associated with the clk to recalculate for > + * > + * Use clk_hw_recalc_rate() for the hw clk where the rate > + * entirely depend on register configuration and doesn't have > + * a .set_rate() OP. In such case, after modifying the register > + * that would change the rate for the hw clk, call > + * clk_hw_recalc_rate() to sync the CCF with the new clk rate. > + */ > +void clk_hw_recalc_rate(const struct clk_hw *hw) > +{ > + struct clk_core *core = hw->core; > + > + if (!core || !(core->flags & CLK_GET_RATE_NOCACHE)) > + return; > + > + clk_prepare_lock(); > + __clk_recalc_rates(core, false, 0); > + clk_prepare_unlock(); > +} > +EXPORT_SYMBOL_GPL(clk_hw_recalc_rate); There's no user of this new function. You need to also include a user so that we can see the complete picture of how this will be used. If it helps to demonstrate the problem, you can also add to the clk kunit tests in drivers/clk/clk_test.c. Brian