From: SeungJong Ha <engineer.jjhama@gmail.com>

Add the HeaderType enum to represent PCI configuration space header
types (Normal and Bridge). Also implement the header_type() method in
the Device struct to allow Rust PCI drivers to identify the device
type safely.

This is required for drivers to handle type-specific configuration
registers correctly.

Signed-off-by: SeungJong Ha <engineer.jjhama@gmail.com>
---
Hello,

This is my first patch to the Linux kernel, specifically targeting the 
Rust PCI subsystem. 

This patch introduces the HeaderType enum to represent PCI configuration 
space header types (Normal and Bridge) and implements the header_type() 
method in the Device struct.

I have followed the patch submission checklist, but as this is my first 
contribution, please let me know if I have missed any conventions or 
if there are areas for improvement.

Thank you for your time and review!

Best regards,
SeungJong Ha
---
 rust/kernel/pci.rs        | 10 ++++++++++
 rust/kernel/pci/header.rs | 31 +++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
index 82e128431..90a0eb54f 100644
--- a/rust/kernel/pci.rs
+++ b/rust/kernel/pci.rs
@@ -31,10 +31,12 @@
     },
 };
 
+mod header;
 mod id;
 mod io;
 mod irq;
 
+pub use self::header::HeaderType;
 pub use self::id::{
     Class,
     ClassMask,
@@ -373,6 +375,14 @@ pub fn revision_id(&self) -> u8 {
         unsafe { (*self.as_raw()).revision }
     }
 
+    /// Returns the PCI header type.
+    #[inline]
+    pub fn header_type(&self) -> HeaderType {
+        // SAFETY: By its type invariant `self.as_raw` is always a valid pointer to a
+        // `struct pci_dev`.
+        HeaderType::from(unsafe { (*self.as_raw()).hdr_type })
+    }
+
     /// Returns the PCI bus device/function.
     #[inline]
     pub fn dev_id(&self) -> u16 {
diff --git a/rust/kernel/pci/header.rs b/rust/kernel/pci/header.rs
new file mode 100644
index 000000000..032efeb16
--- /dev/null
+++ b/rust/kernel/pci/header.rs
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! PCI device header type definitions.
+//!
+//! This module contains PCI header type definitions
+
+use kernel::bindings;
+
+/// PCI device header types.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum HeaderType {
+    /// Normal PCI device header (Type 0)
+    NormalDevice,
+    /// PCI-to-PCI bridge header (Type 1)
+    PciToPciBridge,
+    /// CardBus bridge header (Type 2)
+    CardBusBridge,
+    /// Unknown or unsupported header type
+    Unknown,
+}
+
+impl From<u8> for HeaderType {
+    fn from(value: u8) -> Self {
+        match u32::from(value) & bindings::PCI_HEADER_TYPE_MASK {
+            bindings::PCI_HEADER_TYPE_NORMAL => HeaderType::NormalDevice,
+            bindings::PCI_HEADER_TYPE_BRIDGE => HeaderType::PciToPciBridge,
+            bindings::PCI_HEADER_TYPE_CARDBUS => HeaderType::CardBusBridge,
+            _ => HeaderType::Unknown,
+        }
+    }
+}

---
base-commit: f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da
change-id: 20260103-add-rust-pci-header-type-346249c1ec14

Best regards,
-- 
SeungJong Ha <engineer.jjhama@gmail.com>

On Sat Jan 3, 2026 at 3:38 PM CET, SeungJong Ha via B4 Relay wrote:
> This is my first patch to the Linux kernel, specifically targeting the 
> Rust PCI subsystem. 

Thanks for your contribution!

> This patch introduces the HeaderType enum to represent PCI configuration 
> space header types (Normal and Bridge) and implements the header_type() 
> method in the Device struct.

We usually do not add dead code in the kernel. Do you work on a user for this
API?

2026년 1월 4일 (일) AM 12:17, Danilo Krummrich <dakr@kernel.org>님이 작성:
>
> On Sat Jan 3, 2026 at 3:38 PM CET, SeungJong Ha via B4 Relay wrote:
> > This is my first patch to the Linux kernel, specifically targeting the
> > Rust PCI subsystem.
>
> Thanks for your contribution!
>
> > This patch introduces the HeaderType enum to represent PCI configuration
> > space header types (Normal and Bridge) and implements the header_type()
> > method in the Device struct.
>
> We usually do not add dead code in the kernel. Do you work on a user for this
> API?

Hi Danilo, Thanks for your feedback.

Yes, I am currently developing a Rust-based driver for nvme and ixgbe devices,
which requires identifying the header type to check compatibility on
initialization.
I sent this patch first as it provides a foundational API for the PCI
abstraction.

Best regards, SeungJong Ha

On Sat Jan 3, 2026 at 4:39 PM CET, 하승종 wrote:
> 2026년 1월 4일 (일) AM 12:17, Danilo Krummrich <dakr@kernel.org>님이 작성:
>>
>> On Sat Jan 3, 2026 at 3:38 PM CET, SeungJong Ha via B4 Relay wrote:
>> > This is my first patch to the Linux kernel, specifically targeting the
>> > Rust PCI subsystem.
>>
>> Thanks for your contribution!
>>
>> > This patch introduces the HeaderType enum to represent PCI configuration
>> > space header types (Normal and Bridge) and implements the header_type()
>> > method in the Device struct.
>>
>> We usually do not add dead code in the kernel. Do you work on a user for this
>> API?
>
> Hi Danilo, Thanks for your feedback.
>
> Yes, I am currently developing a Rust-based driver for nvme and ixgbe devices,
> which requires identifying the header type to check compatibility on
> initialization.
> I sent this patch first as it provides a foundational API for the PCI
> abstraction.

As Miguel also pointed out in his reply, I'd like to see a patch series with the
driver as an RFC patch.

If it is working, not too far from an "upstreamable" state and the subsystem
maintainers of the driver's target subsystem are indicating willingness to
eventually take the driver, I'm happy to go ahead and merge any dependencies.

- Danilo

2026년 1월 4일 (일) PM 10:40, Danilo Krummrich <dakr@kernel.org>님이 작성:
>
> On Sat Jan 3, 2026 at 4:39 PM CET, 하승종 wrote:
> > 2026년 1월 4일 (일) AM 12:17, Danilo Krummrich <dakr@kernel.org>님이 작성:
> >>
> >> On Sat Jan 3, 2026 at 3:38 PM CET, SeungJong Ha via B4 Relay wrote:
> >> > This is my first patch to the Linux kernel, specifically targeting the
> >> > Rust PCI subsystem.
> >>
> >> Thanks for your contribution!
> >>
> >> > This patch introduces the HeaderType enum to represent PCI configuration
> >> > space header types (Normal and Bridge) and implements the header_type()
> >> > method in the Device struct.
> >>
> >> We usually do not add dead code in the kernel. Do you work on a user for this
> >> API?
> >
> > Hi Danilo, Thanks for your feedback.
> >
> > Yes, I am currently developing a Rust-based driver for nvme and ixgbe devices,
> > which requires identifying the header type to check compatibility on
> > initialization.
> > I sent this patch first as it provides a foundational API for the PCI
> > abstraction.
>
> As Miguel also pointed out in his reply, I'd like to see a patch series with the
> driver as an RFC patch.
>
> If it is working, not too far from an "upstreamable" state and the subsystem
> maintainers of the driver's target subsystem are indicating willingness to
> eventually take the driver, I'm happy to go ahead and merge any dependencies.
>
> - Danilo

Hi Danilo, Muguel!

Thank you for the encouragement and the clear guidance.
Since my current driver implementation is still in a very early stage
and not yet
ready for public review, I will focus on maturing the codebase first.
I will come back with an RFC patch series that includes both the PCI
abstractions
and the driver once it reaches a more stable state.
Thank you again for your kind feedback and for guiding me through my first patch
submission.

- SeungJong Ha

On Sat, Jan 3, 2026 at 4:39 PM 하승종 <engineer.jjhama@gmail.com> wrote:
>
> Yes, I am currently developing a Rust-based driver for nvme and ixgbe devices,
> which requires identifying the header type to check compatibility on
> initialization.
> I sent this patch first as it provides a foundational API for the PCI
> abstraction.

In those cases it is usually a good idea to show the initial user of
the API, even if as an RFC patch, typically as a final patch in a
series.

Even then, landing the abstractions usually need to wait for the
concrete user to be ready to land, depending on what Danilo et al.
decide.

Thanks!

Cheers,
Miguel