All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Timur Tabi <ttabi@nvidia.com>,
	"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	Joel Fernandes <joelagnelf@nvidia.com>,
	"dakr@kernel.org" <dakr@kernel.org>,
	"lyude@redhat.com" <lyude@redhat.com>,
	Alexandre Courbot <acourbot@nvidia.com>,
	"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH v2 12/13] gpu: nova-core: add PIO support for loading firmware images
Date: Tue, 2 Dec 2025 16:35:04 -0800	[thread overview]
Message-ID: <d94e68d7-84a7-4540-8de8-5f163d22d763@nvidia.com> (raw)
In-Reply-To: <44986645d9ecb62887f8d3506533d4ef369af69a.camel@nvidia.com>

On 12/2/25 3:48 PM, Timur Tabi wrote:
> On Tue, 2025-12-02 at 15:40 -0800, John Hubbard wrote:
>> In fact, I just finished looking through my Hopper/Blackwell PIO code, which
>> also needs 4-byte alignment, and concluded that returning -EINVAL for misaligned
>> data seems to be the appropriate way to handle things.
> 
> I've added this for v3:
> 
>         // Rejecting misaligned images here allows us to avoid checking
>         // inside the loops.
>         if img.len() % 4 != 0 {
>             return Err(EINVAL);
>         }

Looks good.

> 
> And I manually create the &[u8; 4] now:
> 
>             for word in block.chunks_exact(4) {
>                 let w = [word[0], word[1], word[2], word[3]];

Yes, this is probably the best way. Although...

>                 regs::NV_PFALCON_FALCON_IMEMD::default()
>                     .set_data(u32::from_le_bytes(w))
>                     .write(bar, &E::ID, port);
> 
> word[3] will always exist because of chunks_exact(4).
> 

Interesting, I was just looking at this, and the 4-byte manual
construction bothered me a little ("why must I do this?"), so I'm
currently wondering if "// PANIC..." plus an "infallible" .unwrap()
is reasonable, for example:

impl Falcon<Fsp> {
...
    pub(crate) fn write_emem(&self, bar: &Bar0, offset: u32, data: &[u8]) -> Result {
        if offset % 4 != 0 || data.len() % 4 != 0 {
            return Err(EINVAL);
        }
...
        for chunk in data.chunks_exact(4) {
            // PANIC: `chunks_exact(4)` guarantees each chunk is exactly 4 bytes.
            let word = u32::from_le_bytes(chunk.try_into().unwrap());
            regs::NV_PFALCON_FALCON_EMEM_DATA::default()
                .set_data(word)
                .write(bar, &Fsp::ID);
        }

...but actually, I think your way is better, because you don't have
just justify an .unwrap().

What do you think?

I figured you'd enjoy this, coming as it does just one email after I
wrote "never .unwrap()". haha :)

thanks,
-- 
John Hubbard


  reply	other threads:[~2025-12-03  0:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-01 23:39 [PATCH v2 00/13] gpu: nova-core: add Turing support Timur Tabi
2025-12-01 23:39 ` [PATCH v2 01/13] gpu: nova-core: rename Imem to ImemSecure Timur Tabi
2025-12-01 23:39 ` [PATCH v2 02/13] gpu: nova-core: add ImemNonSecure section infrastructure Timur Tabi
2025-12-01 23:39 ` [PATCH v2 03/13] gpu: nova-core: support header parsing on Turing/GA100 Timur Tabi
2025-12-01 23:39 ` [PATCH v2 04/13] gpu: nova-core: add support for Turing/GA100 fwsignature Timur Tabi
2025-12-01 23:39 ` [PATCH v2 05/13] gpu: nova-core: add NV_PFALCON_FALCON_DMATRFCMD::with_falcon_mem() Timur Tabi
2025-12-01 23:39 ` [PATCH v2 06/13] gpu: nova-core: add Turing boot registers Timur Tabi
2025-12-01 23:39 ` [PATCH v2 07/13] gpu: nova-core: move some functions into the HAL Timur Tabi
2025-12-01 23:39 ` [PATCH v2 08/13] gpu: nova-core: Add basic Turing HAL Timur Tabi
2025-12-01 23:39 ` [PATCH v2 09/13] gpu: nova-core: add Falcon HAL method supports_dma() Timur Tabi
2025-12-01 23:39 ` [PATCH v2 10/13] gpu: nova-core: add FalconUCodeDescV2 support Timur Tabi
2025-12-01 23:39 ` [PATCH v2 11/13] gpu: nova-core: align LibosMemoryRegionInitArgument size to page size Timur Tabi
2025-12-01 23:39 ` [PATCH v2 12/13] gpu: nova-core: add PIO support for loading firmware images Timur Tabi
2025-12-02 21:23   ` Joel Fernandes
2025-12-02 22:51     ` Timur Tabi
2025-12-02 23:20       ` Joel Fernandes
2025-12-02 23:40         ` John Hubbard
2025-12-02 23:48           ` Timur Tabi
2025-12-03  0:35             ` John Hubbard [this message]
2025-12-03  0:42               ` Timur Tabi
2025-12-03  0:45                 ` John Hubbard
2025-12-03  2:14                   ` Joel Fernandes
2025-12-03  2:21                     ` John Hubbard
2025-12-02 21:28   ` Joel Fernandes
2025-12-01 23:39 ` [PATCH v2 13/13] [RFC] gpu: nova: implement trait object FalconUCodeDescriptor Timur Tabi
2025-12-02  3:00   ` John Hubbard
2025-12-02  2:55 ` [PATCH v2 00/13] gpu: nova-core: add Turing support John Hubbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d94e68d7-84a7-4540-8de8-5f163d22d763@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=joelagnelf@nvidia.com \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=ttabi@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.