From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, "David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
nova-gpu@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 01/31] rust: pci: add domain_nr() accessor
Date: Sun, 23 Aug 2026 09:08:42 +0900 [thread overview]
Message-ID: <DKVVX264VFKR.347534AM9TW1T@nvidia.com> (raw)
In-Reply-To: <4a092657-eed7-45ae-a63f-3370c9f9a09b@nvidia.com>
On Sun Aug 23, 2026 at 5:11 AM JST, John Hubbard wrote:
> On 8/22/26 12:57 AM, Miguel Ojeda wrote:
>> On Sat, Aug 22, 2026 at 3:55 AM John Hubbard <jhubbard@nvidia.com> wrote:
>>>
>>> + // CAST: The C function returns `int`, but a PCI domain number is always
>>> + // non-negative, so this cast will not lose any information.
>>> + domain_nr as u32
>>
>> What about
>>
>> debug_assert!(domain_nr >= 0);
>>
>> ?
>
> Yes, good idea. That's appropriate because the PCI core on the C side
> provides a positive domain number, and the Rust side can assert that
> that continues to be true.
>
> I'll add it right after the "let domain_nr..." statement, when I send
> the next version.
>
> (Although I would like to figure out some way to get this in ahead of
> things, one way or another.)
Since this is a very similar case I thought that maybe we can fix the C
API to return an unsigned like we did in [1], but things appear to be a
bit more intricate here and a negative number is (temporarily) stored at
least once (`PCI_DOMAIN_NR_NOT_SET`).
So indeed `debug_assert` sounds like the right call (and maybe we should
have one in [2] as well)
[1] https://patch.msgid.link/20260722073913.1807677-2-zhiw@nvidia.com
[2] https://patch.msgid.link/20260722073913.1807677-3-zhiw@nvidia.com
next prev parent reply other threads:[~2026-08-23 0:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 1:54 [PATCH v2 00/31] gpu: nova-core: boot on the r000 GSP firmware John Hubbard
2026-08-22 1:54 ` [PATCH v2 01/31] rust: pci: add domain_nr() accessor John Hubbard
2026-08-22 7:57 ` Miguel Ojeda
2026-08-22 20:11 ` John Hubbard
2026-08-23 0:08 ` Alexandre Courbot [this message]
2026-08-22 1:54 ` [PATCH v2 02/31] gpu: nova-core: firmware: add r000 bindings John Hubbard
2026-08-22 1:54 ` [PATCH v2 03/31] gpu: nova-core: extract radix3 page table into its own module John Hubbard
2026-08-22 1:54 ` [PATCH v2 04/31] gpu: nova-core: set MCTP transport header version to 1 John Hubbard
2026-08-22 1:54 ` [PATCH v2 05/31] gpu: nova-core: add Falcon helpers for r000 LOAD_EXEC events John Hubbard
2026-08-22 1:54 ` [PATCH v2 06/31] gpu: nova-core: zero-pad radix3 page table levels to page boundary John Hubbard
2026-08-22 1:54 ` [PATCH v2 07/31] gpu: nova-core: distinguish async GSP RPC traffic in debug logs John Hubbard
2026-08-22 1:54 ` [PATCH v2 08/31] gpu: nova-core: add optional ucodes firmware loading John Hubbard
2026-08-23 16:26 ` M Henning
2026-08-23 19:51 ` John Hubbard
2026-08-22 1:54 ` [PATCH v2 09/31] gpu: nova-core: add LIBOS3 log buffers and state monitor buffer John Hubbard
2026-08-22 1:54 ` [PATCH v2 10/31] gpu: nova-core: add build ID headers to debugfs log buffer dumps John Hubbard
2026-08-22 1:54 ` [PATCH v2 11/31] gpu: nova-core: rename the FbRanges elf field to fw_image John Hubbard
2026-08-22 1:54 ` [PATCH v2 12/31] gpu: nova-core: regs: add msgq v2 BAR0 register declarations John Hubbard
2026-08-22 1:54 ` [PATCH v2 13/31] gpu: nova-core: gsp: add msgq v2 internals John Hubbard
2026-08-22 1:54 ` [PATCH v2 14/31] gpu: nova-core: generalize allocate_command() for variable headers John Hubbard
2026-08-22 1:54 ` [PATCH v2 15/31] gpu: nova-core: add GMC API message types John Hubbard
2026-08-22 1:54 ` [PATCH v2 16/31] gpu: nova-core: add GMC send path John Hubbard
2026-08-22 1:54 ` [PATCH v2 17/31] gpu: nova-core: add GMC transport receive path John Hubbard
2026-08-22 1:54 ` [PATCH v2 18/31] gpu: nova-core: gsp: add GMC dispatch on receive John Hubbard
2026-08-22 1:54 ` [PATCH v2 19/31] gpu: nova-core: separate the generic falcon bootloader from FWSEC John Hubbard
2026-08-22 1:54 ` [PATCH v2 20/31] gpu: nova-core: handle the r000 load-and-execute HS binary event John Hubbard
2026-08-22 1:54 ` [PATCH v2 21/31] gpu: nova-core: handle the r000 load-and-execute bootloader event John Hubbard
2026-08-22 1:54 ` [PATCH v2 22/31] gpu: nova-core: gsp: add the GMC boot event dispatcher John Hubbard
2026-08-22 1:54 ` [PATCH v2 23/31] gpu: nova-core: gsp: add the GSP_INIT request builder John Hubbard
2026-08-22 1:54 ` [PATCH v2 24/31] gpu: nova-core: gsp: send GSP_INIT and decode its reply John Hubbard
2026-08-22 1:54 ` [PATCH v2 25/31] gpu: nova-core: gsp: pass the remaining log buffers to GSP-RM John Hubbard
2026-08-22 1:54 ` [PATCH v2 26/31] gpu: nova-core: switch to the r000 GSP firmware John Hubbard
2026-08-22 1:54 ` [PATCH v2 27/31] gpu: nova-core: gsp: validate RPC element framing on receive John Hubbard
2026-08-22 1:54 ` [PATCH v2 28/31] gpu: nova-core: gsp: remove the RPCs that GSP_INIT replaced John Hubbard
2026-08-22 1:54 ` [PATCH v2 29/31] gpu: nova-core: firmware: delete the r570 bindings John Hubbard
2026-08-22 1:54 ` [PATCH v2 30/31] gpu: nova-core: print GMC command names in debug logs John Hubbard
2026-08-22 1:54 ` [PATCH v2 31/31] gpu: nova-core: distinguish GMC event and response " 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=DKVVX264VFKR.347534AM9TW1T@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=zhiw@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®