arm64/riscv nexus: Implement bus_unmap_resource

[imp]

sys/arm64/arm64/nexus.c

506

Do we even have ioport references on !x86?

[jhb]

sys/arm64/arm64/nexus.c

506

IO bars are still a thing in PCI and always send up as SYS_RES_IOPORT from the PCI bus driver up to its parent. Up to the platform how it chooses to map those resources, usually to some alternate MMIO window.

[jhb]

sys/arm64/arm64/nexus.c

451

Note that deactivate_resource uses bus_space_unmap, but complementing the pmap_mapdev() in nexus_map_resource() seems more correct.

[jrtc27]

sys/arm64/arm64/nexus.c

506

All the way up to nexus? Would the PCI controller driver not be the thing that remaps it to a memory range? That’s normally where the decision gets made as to what it means. Though perhaps it still gets identified as an I/O port beyond that, just using the same memory address space? But dodgy if so though…

[jhb]

sys/arm64/arm64/nexus.c

506

That's what happens today, yes. It depends a bit on "who" defines the backing MMIO range for I/O ports.

Note though that this is not new, the existing nexus_map_resource function already handles SYS_RES_IOPORT and this is just mirroring that.

[jrtc27]

sys/arm64/arm64/nexus.c

506

Which happens? If the controller's turning into SYS_RES_MEMORY, I would expect it to be an error to have SYS_RES_IOPORT reach nexus for arm64 or riscv given that has no sane meaning.

[jhb]

sys/arm64/arm64/nexus.c

506

I think "bubbles all the way up to nexus" is what happens today. However, in this particular set of work I'm refactoring the existing code that is already here to reduce duplication across platforms (and also I would like working map/unmap_resource to fix a long-standing layering violation down in sys/dev/pci/pci_pci.c). Whether or not SYS_RES_IOPORT should be handled differently in the various PCI controller drivers is orthogonal to this change.