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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 ADEBAC6FD20 for ; Tue, 21 Mar 2023 23:55:12 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7380910E004; Tue, 21 Mar 2023 23:55:11 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id C741310E004 for ; Tue, 21 Mar 2023 23:55:08 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id E582FB816ED; Tue, 21 Mar 2023 23:55:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95BB6C433EF; Tue, 21 Mar 2023 23:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679442905; bh=Zmz+zFJqVc5SKCrgmnXSfAha9+ORxpYl8yLYMGMMags=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=vC+aPija08rwI0Z0SCC6TQmecCZUnv4kBRG5bUWq4oYuCh+42hNg59KRj7ooNvAjt 0q0FQWa86ld9KLPmMjkZN8lTIHAXgAI6+lIDL2fHz4l8k1cxRd3ZoVTtqbSuG3X2jB 74pA+6tcit6gt9Q97zO8pwWLFl/yckFNnX/nlDRmuMz0GINKVfZO0FLUjT/HLKgr9g 7f02ip0HHmm6kXdGMavcuXeslpF/J5ZUbMOQRPRJpC6o2sbii/Rs3MX+3w/Sbx5rWO KpF00mRwuB9S8RXVbMZRYoGt3OhqjW1z29iRQHJsocvvizBcCtPmySahlQ1kxvcUCN 5JQkltE/Zmu+g== Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> References: <20221018-clk-range-checks-fixes-v2-0-f6736dec138e@cerno.tech> Subject: Re: [PATCH v2 00/65] clk: Make determine_rate mandatory for muxes From: Stephen Boyd To: Abel Vesa , Alessandro Zummo , Alexandre Belloni , Alexandre Torgue , Andreas =?utf-8?q?F=C3=A4rber?= , Baolin Wang , Charles Keepax , Chen-Yu Tsai , Chunyan Zhang , Claudiu Beznea , Daniel Vetter , David Airlie , David Lechner , Dinh Nguyen , Fabio Estevam , Geert Uytterhoeven , Jaroslav Kysela , Jernej Skrabec , Jonathan Hunter , Kishon Vijay Abraham I , Liam Girdwood , Linus Walleij , Luca Ceresoli , Manivannan Sadhasivam , Mark Brown
, Matthias Brugger , Max Filippov , Maxime Coquelin , Maxime Ripard , Michael Turquette , NXP Linux Team , Nicolas Ferre , Orson Zhai , Paul Cercueil , Pengutronix Kernel Team , Peter De Schrijver , Prashant Gaikwad , Richard Fitzgerald , Samuel Holland , Sascha Hauer , Sekhar Nori , Shawn Guo , Takashi Iwai , Thierry Reding , Ulf Hansson , Vinod Koul Date: Tue, 21 Mar 2023 16:55:03 -0700 User-Agent: alot/0.10 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-rtc@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, patches@opensource.cirrus.com, linux-actions@lists.infradead.org, linux-mips@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-tegra@vger.kernel.org, linux-mediatek@lists.infradead.org, Maxime Ripard , linux-phy@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Quoting Maxime Ripard (2022-11-04 06:17:17) > Hi, >=20 > This is a follow-up to a previous series that was printing a warning > when a mux has a set_parent implementation but is missing > determine_rate(). >=20 > The rationale is that set_parent() is very likely to be useful when > changing the rate, but it's determine_rate() that takes the parenting > decision. If we're missing it, then the current parent is always going > to be used, and thus set_parent() will not be used. The only exception > being a direct call to clk_set_parent(), but those are fairly rare > compared to clk_set_rate(). >=20 > Stephen then asked to promote the warning to an error, and to fix up all > the muxes that are in that situation first. So here it is :) >=20 > Let me know what you think, What's the plan here? Are you going to resend?