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 62CD3ECD6C7 for ; Wed, 11 Feb 2026 16:47:20 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C83E610E638; Wed, 11 Feb 2026 16:47:19 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="HD0OiU/X"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5437A10E09B for ; Wed, 11 Feb 2026 16:47:18 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 668F960053; Wed, 11 Feb 2026 16:47:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B434C4CEF7; Wed, 11 Feb 2026 16:47:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770828437; bh=Axd6+FAx+svU01taZF9dBwsFOMn//n4UUyQCxOZzxLE=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=HD0OiU/X9XdxIPhqSht4yMAhClrCU0+gnVun0CaAq5Yb9HV7dl3p8e2GOuzP81AKF LjXvjZqzFdaux5+yWWAZsZ5CqvQqa6Ab+c99OfMXICjFS3xCHxzgWrR2iSI5CqvZt+ F8nVhOZTY8JCg42YOpMEXhZ5+3qYBGKaAM8OJvKHaTfEw4H0N5K6GQ37DacuCQs+sN Yxah6cvl7+np9/YZHGg/IMr+itaSy5o5Ve4aiV0tSw+3DE+wpnfRoVaye1PMmcPa7K WMlcMazd4fO80Pw3fNwBlK0HRNFHEHdmBgVbHVme1p+R2iaqooeeLy9/wuBwK+9tAE S0nGTPkw+HslQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 11 Feb 2026 17:47:09 +0100 Message-Id: Cc: "Boris Brezillon" , "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" From: "Danilo Krummrich" Subject: Re: [PATCH v3 1/3] rust: clk: use the type-state pattern References: <518D8B09-B9A1-4DB4-85CD-37A2DD3D5FB1@collabora.com> <20260119-weightless-pelican-of-anger-190db0@houat> <20260122-majestic-masterful-jaguarundi-d0abde@houat> <2F3D3A40-6EF9-46FC-A769-E5A3AAF67E65@collabora.com> <20260204-nickel-seal-of-poetry-8fdefb@houat> <91A92D84-1F2E-45F3-82EC-6A97D32E2A78@collabora.com> <20260204-angelic-vermilion-beagle-fd1507@houat> <20260209105047.693f2515@fedora> <20260211-flawless-feathered-boar-0b87ad@houat> In-Reply-To: <20260211-flawless-feathered-boar-0b87ad@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 Wed Feb 11, 2026 at 5:37 PM CET, Maxime Ripard wrote: > I do think we can find a compromise though. Miguel suggested for example > to make the current enable/prepare/disable/unprepare function unsafe, > and that's totally reasonable to me. > > Then we can implement the "managed" clock version on that unsafe API, What do you mean with "managed" clock? Do you mean devres managed? If so, I don't think there is any reason to switch to the unsafe API to be able to implement devres managed APIs (see also [1]). [1] https://lore.kernel.org/all/DFVW9MS5YLON.CVJDBYQKJ0P6@kernel.org/ > and we would end up with a "raw", unsafe, version kind of equivalent to > the one we have today, and where callers would have to justify why their > usage of the API is actually safe, or the new, managed, variant that is > safe and can be easily used by most drivers. > > And we can call these RawClk vs Clk, or Clk vs ManagedClk, or whatever. > > How does that sound? What about we just wait until we have a user that really requires an unsafe= API for some reason? And if it never appears, even better. :)