Home | History | Annotate | Download | only in pci
History log of /src/sys/dev/pci/pci_resource.h
RevisionDateAuthorComments
 1.2  03-Mar-2025  riastradh pci_resource(9): Handle multiple ranges of the same type.

Rather than having the caller fill in an array indexed by range type
of a single start/end pair for each type, the caller will now do:

struct pci_resource_info info;

memset(&info, 0, sizeof(info));

pci_resource_add_range(&info, PCI_RANGE_MEM, mstart1, mend1);
pci_resource_add_range(&info, PCI_RANGE_MEM, mstart2, mend2);
pci_resource_add_range(&info, PCI_RANGE_MEM, mstart3, mend3);
pci_resource_add_range(&info, PCI_RANGE_PMEM, pstart1, pend1);
pci_resource_add_range(&info, PCI_RANGE_IO, iostart1, ioend1);
...

While here, fix a format string -- 0x% or %# is enough to say that
the output is hexadecimal; we don't need to belabour the point by
printing a `0x0x' prefix!

XXX While this handles multiple io/mem/prefetchable-mem ranges, it
doesn't yet handle multiple bus ranges, which we have seen in
practice, e.g. on orion o6. TBD.

ok jmcneill@

PR port-amd64/59118: Thinkpad T495s - iwm PCI BAR is zero
 1.1  14-Oct-2022  jmcneill Add a PCI resource manager and use it on Arm ACPI platforms.

The Arm ACPI code relied on PCI_NETBSD_CONFIGURE to configure devices that
were not enabled by system firmware. This is not safe to do unless the
firmware explicitly permits it using a device specific method defined in
the PCI firmware spec.

Introduce a new PCI resource manager that discovers what has already been
configured by firmware and allocates from the remaining space. This will
ensure that devices setup by firmware are untouched and only will program
BARs of devices that are not enabled at boot time.

The current implementation assumes that the parent PCI-PCI bridge's
are already configured. A worthwhile improvement in the future would be
to support programming windows for bridges that are not fully configured.

RSS XML Feed