[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0192e318-f89e-4152-ad79-d93d7a8eafc0@nvidia.com>
Date: Fri, 29 Aug 2025 14:48:02 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>,
Danilo Krummrich <dakr@...nel.org>
Cc: Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
Alistair Popple <apopple@...dia.com>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Bjorn Helgaas <bhelgaas@...gle.com>,
Krzysztof Wilczyński <kwilczynski@...nel.org>,
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>,
nouveau@...ts.freedesktop.org, linux-pci@...r.kernel.org,
rust-for-linux@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Elle Rhumsaa <elle@...thered-steel.dev>
Subject: Re: [PATCH v7 2/6] rust: pci: provide access to PCI Vendor values
On 8/28/25 6:25 AM, Alexandre Courbot wrote:
> On Wed Aug 27, 2025 at 8:12 AM JST, John Hubbard wrote:
...
>> +macro_rules! define_all_pci_vendors {
>> + (
>> + $($variant:ident = $binding:expr,)+
>> + ) => {
>> +
>> + impl Vendor {
>
> Why the blank line here? (same for the `define_all_pci_classes` in the
> previous patch).
Removed in both places, thanks!
...
>> +impl fmt::Display for Vendor {
>> + #[inline]
>> + fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
>> + write!(f, "0x{:04x}", self.0)
>> + }
>> +}
>
> Possibly an exercice for a future patch, but do we want to display the
> vendor name if it is defined, rather than its hex code (which is more
> the job of `Debug`)? We could leverage the macro above to do that. The
> same should be doable for the PCI classes.
>
> I suspect strings for all the names already exist on the C side, in
> which case we would want to reuse them instead of defining new ones.
A reasonable suspicion, but actually, they do not yet exist. So I think
we could just add them on the Rust side.
>
> Note that I don't think this needs to be done for this series - it's
> just a thought as I was looking at this `Display` implementation that
> looks more like a `Debug` one.
Good points. Yes, I can do a follow-up patch.
thanks,
--
John Hubbard
Powered by blists - more mailing lists