All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Timur Tabi <ttabi@nvidia.com>,
	"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	"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 18:21:29 -0800	[thread overview]
Message-ID: <729bf4ea-0a1e-4f09-a4e8-1f5c9ba48a92@nvidia.com> (raw)
In-Reply-To: <126CBF5C-01B9-43D7-B4D7-FD32E2D6D9C4@nvidia.com>

On 12/2/25 6:14 PM, Joel Fernandes wrote:
>> On Dec 2, 2025, at 7:46 PM, John Hubbard <jhubbard@nvidia.com> wrote:
...
>>> 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.
>>>
>>
>> Good question. Maybe someone with Rust experience can enlighten us on
>> that one.
> 
> If the optimizer could not eliminate the dead code, IMO that is a bug, pretty much like how we rely on dead code elimination optimization for build_assert.
> 
> It is worth compiling and checking but I am almost certain the dead code for an unreachable case (in this case, panicking, will be eliminated).
> 

Well yes, but the question remains: is the compiler able to even identify
this as dead code? Because it depends on the early -EINVAL return, in
order to be correct. Is rustc able to figure out that kind of situation?

thanks,
-- 
John Hubbard


  reply	other threads:[~2025-12-03  2:22 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
2025-12-03  0:45                 ` John Hubbard
2025-12-03  2:14                   ` Joel Fernandes
2025-12-03  2:21                     ` John Hubbard [this message]
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=729bf4ea-0a1e-4f09-a4e8-1f5c9ba48a92@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.