Page MenuHomeFreeBSD

pci: avoid accidental clobbering of regs on some fdt platforms
AcceptedPublic

Authored by kevans on Feb 15 2024, 5:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 30, 12:56 PM
Unknown Object (File)
Sun, May 19, 9:53 PM
Unknown Object (File)
May 18 2024, 9:26 AM
Unknown Object (File)
May 17 2024, 12:35 PM
Unknown Object (File)
May 17 2024, 12:32 PM
Unknown Object (File)
May 17 2024, 12:32 PM
Unknown Object (File)
May 13 2024, 12:39 PM
Unknown Object (File)
May 13 2024, 10:25 AM
Subscribers

Details

Reviewers
jhb
Group Reviewers
arm64
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 56438
Build 53326: arc lint + arc unit

Event Timeline

emaste added inline comments.
sys/dev/pci/pci_host_generic.c
183

100 looks rather magic and so warrants a comment IMO

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 marked 4 inline comments as done.

Add a macro, fixup other places, commentary

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.

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.

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.

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.

This revision is now accepted and ready to land.Mar 19 2024, 4:48 PM