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 2309DD29C2D for ; Mon, 19 Jan 2026 14:37:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8845410E470; Mon, 19 Jan 2026 14:37:26 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="g+EN7LOJ"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8DD3C10E470 for ; Mon, 19 Jan 2026 14:37:24 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 3D1C841AD3; Mon, 19 Jan 2026 14:37:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B64A4C116C6; Mon, 19 Jan 2026 14:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768833444; bh=CSTmPBA6jWnROZuwiJTIQySlhBcVu9NnVrQTCL3GAR4=; h=Date:From:Subject:Cc:To:References:In-Reply-To:From; b=g+EN7LOJd5DlifzhjK5E3WGKGFyat9PZSAr8WAdmz92XyVQwA0sE/+zXvsfHrjksQ OzdVmrMR3A/aRfcu/3/a0yumSxnw0rPX+iBlowxF1yAGR8zh/F1xYC90p+YvxlsH3O wMLpMieaxjyyQMQeCeBS1XOvZKPKITy9j2MgViu9ZHZow3Ud3u7Gv8+AziAiCXF8so En3otoLhwMVyrfC6vukQRGMfXLyhBp3d5j6ey6aacwOFGcn+gDlSVGFgm1iS1mX6DW e7vP5v4tJCpBSILrj/cOdTfMrqHDnqSUfdzt0XVst1ej3wx6AJUgrv8QMkU5OLUF5/ HWAhYAbPvnOuw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 19 Jan 2026 15:37:17 +0100 Message-Id: From: "Danilo Krummrich" Subject: Re: [PATCH v3 1/3] rust: clk: use the type-state pattern Cc: "Daniel Almeida" , "Alice Ryhl" , "Rafael J. Wysocki" , "Viresh Kumar" , "Maarten Lankhorst" , "Thomas Zimmermann" , "David Airlie" , "Simona Vetter" , "Drew Fustini" , "Guo Ren" , "Fu Wei" , =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= , "Michael Turquette" , "Stephen Boyd" , "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , , , , , , , To: "Maxime Ripard" References: <20260107-clk-type-state-v3-0-77d3e3ee59c2@collabora.com> <20260107-clk-type-state-v3-1-77d3e3ee59c2@collabora.com> <20260108-delectable-fennec-of-sunshine-ffca19@houat> <98CD0BF6-3350-40B9-B8A9-F569AE3E3220@collabora.com> <20260119-thundering-tested-robin-4be817@houat> <518D8B09-B9A1-4DB4-85CD-37A2DD3D5FB1@collabora.com> <20260119-weightless-pelican-of-anger-190db0@houat> In-Reply-To: <20260119-weightless-pelican-of-anger-190db0@houat> 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon Jan 19, 2026 at 3:18 PM CET, Maxime Ripard wrote: > On Mon, Jan 19, 2026 at 02:13:48PM +0100, Danilo Krummrich wrote: >> On Mon Jan 19, 2026 at 1:54 PM CET, Daniel Almeida wrote: >> >> On 19 Jan 2026, at 09:35, Alice Ryhl wrote: >> >> I think that if you still want an API where you just call enable/disa= ble >> >> directly on it with no protection against unbalanced calls, then that >> >> should be the special API. Probably called RawClk and functions marke= d >> >> unsafe. Unbalanced calls seem really dangerous and use should not be >> >> encouraged. >>=20 >> +1; and unless there is a use-case that requires otherwise, it should no= t even >> be possible to do this at all -- at least for driver code. > > I mean, it's great, it's safe, etc. but it's also suboptimal from a PM > perspective on many platforms. It's totally fine to provide nice, safe, > ergonomic wrappers for the drivers that don't care (or can't, really), > but treating a legitimate optimisation as something we should consider > impossible to do is just weird to me. I said that an unsafe API with potentially unbalanced calls is something we should clearly avoid for drivers. This is *not* equivalent to "treating a legitimate optimisation as something we should consider impossible". If we discover use-cases where the current API doesn't work well, we can invenstigate further. >> > I think we should discourage RawClk if at all possible. But if the con= sensus >> > is that we *really* need this easily-abused thing, I can provide a fol= low-up. >>=20 >> I think we should only do this if there are use-case with no alternative= , so far >> there haven't been any AFAIK. > > I don't really care about which alternative we come up with, but look at > devm_regmap_init_mmio_clk for example. It is a valid use-case that > already exists today, and has had for more than a decade at this point. I don't see the issue with devm_regmap_init_mmio_clk()? It takes a referenc= e count of the clock and prepares it when called and unprepares the clk in dr= ops its reference in regmap_mmio_free_context() called from the devres callback= . That something we can easily do with the current API, no?