Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20221103123328.stzhtq5e2jscjdxd@houat>
References: <20221018-clk-range-checks-fixes-v1-0-f3ef80518140@cerno.tech> <20221018-clk-range-checks-fixes-v1-4-f3ef80518140@cerno.tech> <20221026020800.38AC8C433C1@smtp.kernel.org> <20221103123328.stzhtq5e2jscjdxd@houat>
Subject: Re: [PATCH 4/4] clk: Warn if we register a mux without determine_rate
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     Michael Turquette <mturquette@baylibre.com>,
        linux-kernel@vger.kernel.org,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        linux-clk@vger.kernel.org
To:     Maxime Ripard <maxime@cerno.tech>
Date:   Fri, 04 Nov 2022 11:10:11 -0700
User-Agent: alot/0.10
Message-Id: <20221104181013.A664FC433C1@smtp.kernel.org>
Precedence: bulk

Quoting Maxime Ripard (2022-11-03 05:33:28)
> On Tue, Oct 25, 2022 at 07:07:58PM -0700, Stephen Boyd wrote:
> > There is another case which is a leaf clk that is a mux where you only
> > expect clk_set_parent() to be used, and not clk_set_rate(). This use
> > case is odd though, so I'm not sure how much we care.
>=20
> It looks like there's a good number of clocks that do indeed only
> provide get_parent / set_parent. It's hard to tell if it's an oversight
> or a choice.
>=20
> I think we can make that decision explicit by providing a determine_rate
> helper that always returns the current parent and its rate. It shouldn't
> change anything from a CCF behavior point of view, and it makes it clear
> what the behavior is. And if someone wants something else, then they can
> change it to whatever they want.

Ok sounds like a plan.