Skip to content

Conversation

@seijikun
Copy link
Contributor

@seijikun seijikun commented Nov 22, 2025

Initial implementation for device path generation of discovered pci devices in a PciTree instance.
Unfortunately, it's a bit clunky to use, since you have to query the DevicePath corresponding to your PciRootBridgeIo instance yourself and pass that in:

let mut pci_proto = get_open_protocol::<PciRootBridgeIo>(pci_handle);
let root_device_path = get_open_protocol::<DevicePath>(pci_handle);

let pci_tree = pci_proto.enumerate().unwrap();
for addr in pci_tree {
    // v Would be nicer, if I didn't have to pass root DevicePath in manually here v
    let device_path = pci_tree.device_path(&root_device_path, addr).unwrap();
}

I tried getting the DevicePath of the PciRootBridgeIo instance within PciRootBridgeIo::enumerate() and pass that on to the PciTree, but I couldn't find a way to get the DevicePath instance - other than ugly workarounds.

Best consumed Commit-By-Commit. Contains #1830..

Steps to Undraft

Checklist

  • Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
  • Update the changelog (if necessary)

@seijikun seijikun force-pushed the mr-pci-device_paths branch from ab46f2d to 582714a Compare November 22, 2025 02:34
@phip1611 phip1611 marked this pull request as draft November 22, 2025 09:27
@seijikun seijikun force-pushed the mr-pci-device_paths branch 2 times, most recently from 6f6f35b to 8a4ab00 Compare November 24, 2025 10:44
@seijikun seijikun force-pushed the mr-pci-device_paths branch from 8a4ab00 to c31575d Compare December 14, 2025 20:08
@seijikun seijikun marked this pull request as ready for review December 14, 2025 20:13
@phip1611 phip1611 self-requested a review December 14, 2025 22:24
Copy link
Member

@phip1611 phip1611 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with two nits!

PS: You do not have to fix it here but do you have an opinion on #1817? I'd like to hear a direction that we should go for (Box<DevicePath> vs PoolDevicePath)


/// Returns an owned pool copy of this path.
#[cfg(feature = "alloc")]
pub fn to_pool(&self) -> Result<PoolDevicePath, DevicePathUtilitiesError> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if I'm wrong but I think #[cfg(feature = "alloc")] is not needed here. PoolDevicePath works with the underlying UEFI allocator and does not interfer with the global Rust allocator at all?

The feature alloc is only for the global Rust allocator and not all allocations in general.


/// Error type used by the device path construction of [`PciTree`].
#[derive(Debug)]
pub enum PciDevicePathBuildError {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should implement core::error::Error and should also implement fn source() properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants