Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp778992pxb; Tue, 5 Apr 2022 22:59:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6iyv71SQv5/3lWxmPsz9Q3K/tb5/QxC/m3zm4r5WaNaHNP4betLWekhnlU3Ttf5pyLQ08 X-Received: by 2002:a17:902:8f81:b0:154:be2d:1948 with SMTP id z1-20020a1709028f8100b00154be2d1948mr6950408plo.110.1649224764687; Tue, 05 Apr 2022 22:59:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649224764; cv=none; d=google.com; s=arc-20160816; b=aT0lXoinedzE/0AbZ/uz7Kr2eJrvPZBrTHE7ZhEhxWX6iHuB7lj4qPrQZNbRymMeKw Dq5Lp275cxePY5Es0tk6mypy+rdNdWDqrO1rhOVh51T8y+fFD0w9hQQh1337UCywRPuA +O2EVaS4pbON0FwN3e7n5ZjCfpxRVLETMyCLIwdpzfiK6VbbAEaW0BAfIctw7qvaBFgj VfU43bzSebKlvGMbEpEbYC8j2GS8VHt9UBKXZx6jNyw09dazUFVswW0XQvdAWROm5yS/ aev2VxFc2DMCBLXTRshs+BQMKXv8uKKKKYkNLVLSCBLAGs00r3LW8HcJCpvO16XLWdB3 FkDQ== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=ZTie8jl+nmKE6//DNKU/mKyA7EGdtKaIDewTxalawM8=; b=x+h6aGWOF91mfNumleoOw9uXEkhnDvxMcA6zb2jZIzp5BtPvUwkc7YKP2L8KacC+wT ajALneUeKMmMYzKbcMZhzmE82y7L+INcRFB0ZhDnE1aZuNZPQ6xQEoFj5pm7mOOtAT2U 23Fb9zC9WLDReQxBlriBhzFB4z8EPGYkLvw9ZPoiEtl6iUK4/xeB9dXjm0LUFI4dzHdJ oKRTp0+xC+9BpVEKQjevb1jBfAQGn0KaY4RNGls7ywrcO37oyDJGR3LLxRZfuGPnIr9A 2tyRwJD8JbKLh2Sq7pvpiWUVlSD5MoO9GUXGS729yc0/73L92zOkB7YWMXgFIGVfoykk f2Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DzusMr6d; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 10-20020a63154a000000b0039815687f74si740834pgv.839.2022.04.05.22.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Apr 2022 22:59:24 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=DzusMr6d; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2A94D2571F5; Tue, 5 Apr 2022 22:36:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1842547AbiDFBby (ORCPT + 99 others); Tue, 5 Apr 2022 21:31:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350071AbiDEJwk (ORCPT ); Tue, 5 Apr 2022 05:52:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8ED5148893; Tue, 5 Apr 2022 02:50:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 180B7615E3; Tue, 5 Apr 2022 09:50:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28E26C385A1; Tue, 5 Apr 2022 09:50:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649152241; bh=pONLUX1/XreyVe65IKeyG1wQLSMZqhZ3jM/+bDVog24=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DzusMr6dAkVj+bAMRNOIm13oh6H3/1pmIxhMS/IMKeUfzuDY8wPRsImVr6WW8lERd VLrtjmtCWfpZbAbW7ocAEVGGzqNVRw5GUuaToUyg3Bz5bks1LhT5C9AgKk461hwAqU kTg0KBEGPs8ywN+V3AZ/3WQPF/8Y2rgOc/nCGbJ8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Osipenko , Maxime Ripard , Stephen Boyd , Sasha Levin Subject: [PATCH 5.15 658/913] clk: Initialize orphan req_rate Date: Tue, 5 Apr 2022 09:28:40 +0200 Message-Id: <20220405070359.561641377@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org From: Maxime Ripard [ Upstream commit 5f7e2af00807f2117650e711a58b7f0e986ce1df ] When registering a clock that doesn't have a recalc_rate implementation, and doesn't have its parent registered yet, we initialize the clk_core rate and 'req_rate' fields to 0. The rate field is later updated when the parent is registered in clk_core_reparent_orphans_nolock() using __clk_recalc_rates(), but the 'req_rate' field is never updated. This leads to an issue in clk_set_rate_range() and clk_put(), since those functions will call clk_set_rate() with the content of 'req_rate' to provide drivers with the opportunity to change the rate based on the new boundaries. In this case, we would call clk_set_rate() with a rate of 0, effectively enforcing the minimum allowed for this clock whenever we would call one of those two functions, even though the actual rate might be within range. Let's fix this by setting 'req_rate' in clk_core_reparent_orphans_nolock() with the rate field content just updated by the call to __clk_recalc_rates(). Fixes: 1c8e600440c7 ("clk: Add rate constraints to clocks") Reported-by: Dmitry Osipenko Tested-by: Dmitry Osipenko # T30 Nexus7 Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220325161144.1901695-2-maxime@cerno.tech [sboyd@kernel.org: Reword comment] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin --- drivers/clk/clk.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 32fd2853e8b2..5cef73a85901 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -3410,6 +3410,19 @@ static void clk_core_reparent_orphans_nolock(void) __clk_set_parent_after(orphan, parent, NULL); __clk_recalc_accuracies(orphan); __clk_recalc_rates(orphan, 0); + + /* + * __clk_init_parent() will set the initial req_rate to + * 0 if the clock doesn't have clk_ops::recalc_rate and + * is an orphan when it's registered. + * + * 'req_rate' is used by clk_set_rate_range() and + * clk_put() to trigger a clk_set_rate() call whenever + * the boundaries are modified. Let's make sure + * 'req_rate' is set to something non-zero so that + * clk_set_rate_range() doesn't drop the frequency. + */ + orphan->req_rate = orphan->rate; } } } -- 2.34.1