Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.

[jhb]

Summary

Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.

The ACPI and OFW PCI bus drivers as well as CardBus override this to
allocate the larger ivars to hold additional info beyond the stock PCI ivars.

This removes the need to pass the size to functions like pci_add_iov_child()
and pci_read_device() simplifying IOV and bus rescanning implementations.

As a result of this and earlier changes, the ACPI PCI bus driver no longer
needs its own device_attach and pci_create_iov_child methods but can use
the methods in the stock PCI bus driver instead.

Ryan, I can't recall if you had suggested this approach previously during
the IOV work. If you did and I asked you to pass dinfo_size around instead,
I apologize. As I looked at the hotplug and bus rescanning stuff I was
really loathing having to override the size in 3 or more places (e.g.
pci_add_children, pci_add_iov_child, and pci_rescan if the rescan method
accepted a size).

I originally thought about having the method just return the size, but
I think returning the object gives more flexibility in the future in case
a subclass driver needs to initialize its additional state to something
other than all-zeroes earlier than the pci_child_added callback.

Test Plan

• booted on amd64 and verified devinfo -v still showed ACPI handles ok
• passed make tinderbox

[rstone]

sys/dev/pci/pci.c

651 ↗

(On Diff #15026)

is it guaranteed that the bus and the device use the same devinfo structure? I thought that I started down this path and then decided that this was not guaranteed. What happens to the child of the nexus, for instance?

[jhb]

sys/dev/pci/pci.c

651 ↗

(On Diff #15026)

This is only called by drivers that call pci_read_device() to allocate and initialize ivars for a child PCI device. Thus, only drivers that are PCI bus drivers are going to call PCI_ALLOC_DEVINFO(). The 'dev' parameter here is not the device ivars are being allocated for (the device_t doesn't exist yet), it is the bus device that is adding the child. First, because kobj requires the first argument to a kobj method to be a pointer to a kobj instance in whose method table the function is found. Second, perhaps in the future some bus driver will need to use some state in its softc to handle devinfo (really ivars) allocation in some way.