pci: avoid accidental clobbering of regs on some fdt platforms

[kevans]

Summary

Most pci controllers will just have a single reg for the config space,
but others (e.g., on Apple Silicon) may have more following that to
describe, e.g., controller port space. Bump the "ranges" rid space up
to avoid overriding these other memory resources.

[emaste]

sys/dev/pci/pci_host_generic.c

183

100 looks rather magic and so warrants a comment IMO

[jhb]

sys/dev/pci/pci_host_generic.c

183

And it needs to be changed in a few other places I noted. Perhaps it would be better to have a RANGE_RID macro that takes the tuple index as an argument. The comment can go with the definition of the macro.

262–264

314–316

[kevans]

Add a macro, fixup other places, commentary

[kevans]

Stash the rid off in the pcie_range, use that everywhere after allocation both
for bus_*_resource() APIs bus also to decide if we're skipping an element to
deallocate.

[jhb]

This is probably fine, but I think you could also just leave the rid member off. I'm working on a series that removes the rid argument from bus_release_resource. My one thought for having the rid in the ranges structure is if we wanted to set the rids and do bus_set_resource in the bus-specific attach routine when the ranges are enumerated, but I'm not sure it's worth moving the code there (where it would have to be duplicated).

sys/dev/pci/pci_host_generic.c

298–301

I'd probably rather keep the size == 0 check since it's what other places that iterate over ranges use to check for a range to ignore, and instead assert the rid value after the continue.

[kevans]

In D43921#1002445, @jhb wrote:

This is probably fine, but I think you could also just leave the rid member off. I'm working on a series that removes the rid argument from bus_release_resource. My one thought for having the rid in the ranges structure is if we wanted to set the rids and do bus_set_resource in the bus-specific attach routine when the ranges are enumerated, but I'm not sure it's worth moving the code there (where it would have to be duplicated).

bus_delete_resource still needs to know about the rid offset, though, and we may not have gotten far enough to have a resource to rman_get_rid

It occurs to me that pci_host_generic_core_detach shouldn't really ever see the case where a resource isn't set but it still has a resource to delete.

[kevans]

Revert back to the size check, assert that we do or do not have a resource
after as appropriate.

rid is retained for the time being because bus_delete_resource needs it
regardless of whether we have a res or not.