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: <20221012135619.wxyzuqheolhypoec@houat>
References: <20221011135548.318323-1-angelogioacchino.delregno@collabora.com> <20221012085555.3nls7ja56vlnaz2w@houat> <c4a1eb9f-016d-c184-e494-c869038b87ff@collabora.com> <20221012094004.jgiyvmbgomiyedik@houat> <6e76f90f-3b6a-330d-6902-b31bf3d33ad4@collabora.com> <20221012114813.6d6adro746w5bd7c@houat> <decfd5e5-a48b-b2d1-f21b-1a4d52e05538@collabora.com> <20221012135619.wxyzuqheolhypoec@houat>
Subject: Re: [PATCH v2] clk: mediatek: clk-mux: Add .determine_rate() callback
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     mturquette@baylibre.com, matthias.bgg@gmail.com,
        chun-jie.chen@mediatek.com, miles.chen@mediatek.com,
        wenst@chromium.org, linux-clk@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        Maxime Ripard <maxime@cerno.tech>
Date:   Fri, 14 Oct 2022 12:36:50 -0700
User-Agent: alot/0.10
Message-Id: <20221014193652.0C745C433D6@smtp.kernel.org>
Precedence: bulk

Quoting Maxime Ripard (2022-10-12 06:56:19)
>=20
> I think we need to address this in multiple ways:
>=20
> - If you have ftrace enabled on that platform, running with "tp_printk
>   trace_event=3Dclk:*" in the kernel command line on a failing kernel wou=
ld
>   be great, so that we can figure out what is happening exactly.
>=20
> - We really need to merge your patch above as well;
>=20
> - And, if we can, we should forbid to register a mux without a
>   determine_rate implementation. We have to take into account that some
>   muxes are going to be RO and won't need a determine_rate
>   implementation at all, but a clock with a set_parent and without a
>   determine_rate seems like a weird combination.
>=20

So should I apply this patch now on clk-next? Given this regression I'm
leaning towards not sending off the clk rate request this merge window
and letting it bake another cycle.