All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timur Tabi <ttabi@nvidia.com>
To: "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>,
	John Hubbard <jhubbard@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: Wed, 3 Dec 2025 00:42:09 +0000	[thread overview]
Message-ID: <5f107927d9ee9dcc1ef02fd09f5e2e5ece3f13fa.camel@nvidia.com> (raw)
In-Reply-To: <d94e68d7-84a7-4540-8de8-5f163d22d763@nvidia.com>

On Tue, 2025-12-02 at 16:35 -0800, John Hubbard wrote:
>         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 agree.  Avoiding unwrap(), even with a comment, is always a good idea.

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

I think your code is effectively identical to mine, except that I don't need the PANIC comment.  I
suspect that in both cases, the compiler cannot tell that each chunk is always 4 bytes and
try_into() will never panic.  In my case, word[3] always exists and will never panic either.  So I'm
guess that the compiler will still emit code to check for panic.  I don't know.


  reply	other threads:[~2025-12-03  0:43 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
2025-12-03  0:42               ` Timur Tabi [this message]
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=5f107927d9ee9dcc1ef02fd09f5e2e5ece3f13fa.camel@nvidia.com \
    --to=ttabi@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rust-for-linux@vger.kernel.org \
    /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.