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 82D90CAC58E for ; Sat, 13 Sep 2025 13:30:46 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 16B8910E035; Sat, 13 Sep 2025 13:30:46 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="HEGru90Q"; 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 CDAB410E035; Sat, 13 Sep 2025 13:30:44 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2D2454194A; Sat, 13 Sep 2025 13:30:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C946C4CEF4; Sat, 13 Sep 2025 13:30:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757770244; bh=uV6AIY3tX6ZFbEbK51nPPUHpEf3Vl5idHgfbQrj2RXs=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=HEGru90QW4kc+aEL2YYRxXYkaCbmNxKMtYkOHgKiH/LaRkWhOjikL2I21k3MEhhWE w6k97DXeAQZ20nIexQdiEnhyxWzyox46F0JEDtqeTThu347OfGa96ORNp7h3TCYYQW weR8QKgDRRahKjU+kRdVLw2DLI3efPoLoX29RTgETFLorDFx0TB4lvMt4+15mIxsQn NMTQyzDWGSBoeUOaXOCBly0alT3C20yHjA3Gag40OIPoiufLibtm9MeuHyd6Iqay9O dnrFoDPTTYMIPfJ38pD3yEO3/EV0YRWx1H/lgF1aM3tNjcy/porZoJ46J3jk44wEOZ QZpSGK4696qnw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 13 Sep 2025 15:30:31 +0200 Message-Id: Subject: Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a dedicated method Cc: "Alexandre Courbot" , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "David Airlie" , "Simona Vetter" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "John Hubbard" , "Alistair Popple" , "Timur Tabi" , , , , To: "Joel Fernandes" From: "Danilo Krummrich" References: <20250911-nova_firmware-v5-0-5a8a33bddca1@nvidia.com> <20250911-nova_firmware-v5-2-5a8a33bddca1@nvidia.com> <20250913010226.GA1478480@joelbox2> In-Reply-To: <20250913010226.GA1478480@joelbox2> X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote: > Any chance we can initialize the locks later? We don't need locking until > after the boot process is completed, and if there's a way we can dynamica= lly > "pin", where we hypothetically pin after the boot process completed, that > might also work. Though I am not sure if that's something possible in > Rust/rust4linux or if it makes sense. We can't partially initialize structures and then rely on accessing initial= ized data only. This is one of the sources for memory bugs that Rust tries to so= lve. You can wrap fields into Option types and initialize them later, which woul= d defer pin-init calls for the price of having Option fields around. However, we should never do such things. If there's the necessity to do something like that, it indicates a design issue. In this case, there's no problem, we can use pin-init without any issues ri= ght away, and should do so. pin-init is going to be an essential part of *every* Rust driver given that= a lot of the C infrastruture that we abstract requires pinned initialization,= such as locks and other synchronization primitives.