From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42D273D3302; Tue, 3 Feb 2026 16:55:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770137746; cv=none; b=OuTtQPWqfhkpRpyseLJg1ulKNYsVm/FS2KJdg2SKmKYsILWdDzFzkdOkXExsldaDLU1ebLYR1TiJDdg86idN7IcbEitsY0TxZ6HtxVhtSn3UyiGSGQ/N4xlO/8nXCuaszo92/xEUHAftirLkfl4INxa5omfWs02jMOim3NlqCIo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770137746; c=relaxed/simple; bh=kV4Ge2gh5t0HmAlwXC8n3adoRIP/5wSBNzlEZwjgwdE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YlWtXD+mqQlN/SeQZXIOH4zIyG5+LqMFBMBdpkCvm4gOAZc0V5tsBGeus6w09XB7EYysIRVNbi/Zym3hyRiVmDHXlepztBC8GwtJFVZKn2acDDZ1WKi5iw/HQSRv04mQhGh2ShkVgBgZnrj0kB9DuEOMVPWKMdywERkCazqbaYQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=SQB8eyyQ; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="SQB8eyyQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770137743; bh=kV4Ge2gh5t0HmAlwXC8n3adoRIP/5wSBNzlEZwjgwdE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SQB8eyyQ7m+9HKt1io93UcEwuHpqqVLhVaeRvzwZEyF6X8SsHu5YfL0Nwg3LvkoWp rpRu700K7s/cTrZj0RFpQBmgbvLE/Gs31SFRRWVIX78vAR8eV8hQvmWVuR+g22BtTC tQ6y3ygF9n2mXKYnkgbI7ezPoNaoJ6SBrmO0/tuilNzm8O8eUG/pbJzzAjLi2Tq9B/ /K7txIANL3FnTYNVLgFB8ygumSmzb6xji2/ZEBFTxSGzQ132DsEKdSlsd43Q7YyC9W CRhDBrkNzYSHqUTXy3L8B1jXkBk41Hq9NzOzCD3H8ydlVSGR42QuORztpZ997mKUA2 fp05L7juKT2dA== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 5CE7E17E1274; Tue, 3 Feb 2026 17:55:42 +0100 (CET) Date: Tue, 3 Feb 2026 17:55:36 +0100 From: Boris Brezillon To: Daniel Almeida Cc: Alice Ryhl , Maxime Ripard , "Rafael J. Wysocki" , Viresh Kumar , Danilo Krummrich , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Drew Fustini , Guo Ren , Fu Wei , Uwe =?UTF-8?B?S2xlaW5lLUs=?= =?UTF-8?B?w7ZuaWc=?= , Michael Turquette , Stephen Boyd , Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?B?QmrDtnJu?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-riscv@lists.infradead.org, linux-pwm@vger.kernel.org, linux-clk@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH v3 1/3] rust: clk: use the type-state pattern Message-ID: <20260203175536.1a77abbc@fedora> In-Reply-To: <4DD13AE1-C85F-450F-93F2-C7C75766E518@collabora.com> 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> <20260203113902.501e5803@fedora> <20260203150855.77c93e22@fedora> <4DD13AE1-C85F-450F-93F2-C7C75766E518@collabora.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 3 Feb 2026 13:28:15 -0300 Daniel Almeida wrote: > >> Now, this may not be the end of the world in this > >> particular case, but for API consistency, I'd say we should probably a= void this > >> behavior. > >>=20 > >> I see that Alice suggested a closure approach. IMHO, we should use that > >> instead. =20 > >=20 > > The closure, while being useful for the above local clk-enablement > > example, doesn't allow for passing some Clk guard around, like > > you would do with a lock Guard, and I believe that's a useful thing to > > have. =20 >=20 >=20 > Wdym? You=E2=80=99d still get a &Clk that you can pass around, i= .e.: >=20 > self.prepared_clk.with_enabled(|clk: &Clk | { > ... use registers, pass &Clk as needed > }); >=20 > This is now not about clone() vs not clone(), but more about limiting the= scope of the > Enabled state, which would cater to the use-case you mentioned IIUC. Fair enough. I guess it's more a matter of taste for that particular case, and I'm not fundamentally opposed to adding this closure approach. What the clone approach allows that's not doable with the closure AFAICT, is something like: let prep_clk =3D Clk::get(...)?.prepare()?; let comp_a =3D MyComponentA { prepared_clk: prep_clk.clone(), } let comp_b =3D MyComponentB { enabled_clk: prep_clk.enable()?, } and have the guarantee that, as long as comp_a is alive the underlying clk is at-least-Prepared, and as long as comp_b is alive the underlying clk is Enabled.