linux-kernel - Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a dedicated method

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e1755470-587b-4a43-8171-3d031b7fb4f4@kernel.org>
Date: Thu, 11 Sep 2025 13:22:18 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 John Hubbard <jhubbard@...dia.com>, Alistair Popple <apopple@...dia.com>,
 Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a
 dedicated method

On 9/11/25 1:04 PM, Alexandre Courbot wrote:
> +    /// Attempt to start the GSP.
> +    ///
> +    /// This is a GPU-dependent and complex procedure that involves loading firmware files from
> +    /// user-space, patching them with signatures, and building firmware-specific intricate data
> +    /// structures that the GSP will use at runtime.
> +    ///
> +    /// Upon return, the GSP is up and running, and its runtime object given as return value.
> +    pub(crate) fn start_gsp(
> +        pdev: &pci::Device<device::Bound>,
> +        bar: &Bar0,
> +        chipset: Chipset,
> +        gsp_falcon: &Falcon<Gsp>,
> +        _sec2_falcon: &Falcon<Sec2>,
> +    ) -> Result<()> {> +        let dev = pdev.as_ref();
> +
> +        let bios = Vbios::new(dev, bar)?;
> +
> +        let fb_layout = FbLayout::new(chipset, bar)?;
> +        dev_dbg!(dev, "{:#x?}\n", fb_layout);
> +
> +        Self::run_fwsec_frts(dev, gsp_falcon, bar, &bios, &fb_layout)?;
> +
> +        // Return an empty placeholder for now, to be replaced with the GSP runtime data.
> +        Ok(())
> +    }

I'd rather create the Gsp structure already, move the code to Gsp::new() and
return an impl PinInit<Self, Error>. If you don't want to store any of the
object instances you create above yet, you can just stuff all the code into an
initializer code block, as you do in the next patch with
gfw::wait_gfw_boot_completion().