We claim to support Active State Power Management, but don't appear to
do anything different in the kernel when it's enabled other than tell
the firmware we do.
This breaks VMware Fusion on Apple Silicon when it's enabled as it
expects the kernel to enable the ports. As it is reported to be needed
on some x86 servers keep it enabled there, but disable on non-x86
architectures.
Reported by: kp, tuexen
Reviewed by: tuexen, mav, imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48303
(cherry picked from commit 143dff0f9ce9a6f03ae5701368c7144b30e2dc39)
In the ACPI attachment add support for the pcib_request_feature method.
This uses the common _OSC handling.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48048
(cherry picked from commit 1f5c50a8617355758510675cb9412f56fed12efc)
In the ACPI attachment support the ACPI_IVAR_HANDLE ivar. While here
use the common ivar function to support the common ivars.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48047
(cherry picked from commit deb36d0c65436d16b04f99cc2a27bd0f3980a6f0)
Allow this to be called from attachments to allow more ivars to be
implemented.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48046
(cherry picked from commit 7cafe75c8c52deffcb3e64200eb4187a52cf202d)
In pci_host_generic.c use a switch statement rather than a series
of if statements.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48045
(cherry picked from commit fafb43abd0dcaf2d36ec7344f46e7e19c42be888)
Push the #ifdefs down into the function body instead of defining
functions conditionally for ease of readability. These aren't
critical paths, so one extra branch in the !PCI_IOV case is not a big
deal.
Requested by: jrtc27
Differential Revision: https://reviews.freebsd.org/D45877
(cherry picked from commit 971c9f57d7e6b55161fecc008e19f00ccaba8060)
For activate/deactivate resource, use a more standard check at the
start of the function since the addition of the PCI_IOV code made this
more complex. For the three recently added methods, just add the
typical check at the beginning that I missed.
This wasn't always fatal as if your system only had PCI device_t's as
children of PCI bus devices it would happen to work ok, but if you
have a non-PCI child device (e.g. an ATA channel) then dereferencing
ivars for non-direct-children could fault.
Reported by: Cirrus-CI (via emaste)
Reviewed by: emaste
Fixes: 871b33ad65ba pci: Consistently use pci_vf_* for suballocated VF memory resources
Differential Revision: https://reviews.freebsd.org/D45499
(cherry picked from commit 56b822a17cde5940909633c50623d463191a7852)
Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.
Reported by: kp
Reviewed by: imp
Tested by: kp (earlier version)
Differential Revision: https://reviews.freebsd.org/D45406
(cherry picked from commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b)
`argsp` is not defined in `generic_pcie_unmap_resource(..)`. Remove the
parameter passed to `bus_generic_unmap_resource(..)` as this parameter
is never passed to `generic_pcie_unmap_resource(..)`.
Fixes: 98056127ddfa ("acpi/pci/vmd: Fix a nit with nested resource mapping requests")
Reported by: Jenkins (aarch64, armv6, armv7, etc)
Differential Revision: https://reviews.freebsd.org/D45493
(cherry picked from commit 637ee1391957acb3ae0f68aef3e2fad76a5ae338)
Some bus drivers use rmans to suballocate resources to child devices.
When the driver for a child device requests a mapping for a
suballocated resource, the bus driver translates this into a mapping
request for a suitable subrange of the original resource the bus
driver allocated from its parent. This nested mapping request should
look like any other resource mapping request being made by the bus
device (i.e. as if the bus device had called bus_map_resource() or
bus_alloc_resource() with RF_ACTIVE).
I had slightly flubbed this last bit though since the direct use of
bus_generic_map/unmap_resource passed up the original child device
(second argument to the underlying kobj interface). While this is
currently harmless, it is not strictly correct as the resource being
mapped is owned by the bus device, not the child and can break for
other bus drivers in the future.
Instead, use bus_map/unmap_resource for the nested request where the
requesting device is now the bus device that owns the parent resource.
Reviewed by: imp
Fixes: 0e1246e33461 acpi: Cleanup handling of suballocated resources
Fixes: b377ff8110e3 pcib: Refine handling of resources allocated from bridge windows
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Fixes: d714e73f7895 vmd: Use bus_generic_rman_* for PCI bus and memory resources
Differential Revision: https://reviews.freebsd.org/D45433
(cherry picked from commit 98056127ddfa36720bcf46edc09843c867784bcb)
QEMU for armv7 includes a PCI memory range whose CPU address is
greater than 4GB. This falls outside the range of armv7's global
mem_rman used by the nexus driver. As a result, pcib0 fails to
attach blocking all PCI devices.
Instead, change the driver to be a bit more tolerant. If allocating a
resource for a range fails, don't fail attaching the entire driver,
but do skip adding the associated PCI range to the relevant rman in
the pcib driver. This will prevent child devices from using BARs that
allocate from this range. In the case of QEMU on armv7 devices can
still allocate from an earlier PCI memory range that is within the
32-bit address space (and in fact none of the firmware-assigned memory
BARs use addresses from the upper range).
While here, reorder the operations on I/O ranges a bit: 1) print the
range under bootverbose first (rather than last) so that the range is
printed before any relevant errors for the range, 2) move
rman_manage_region last after the parent resource has been set and
allocated.
Reported by: markj, Jenkins
Reviewed by: markj
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44698
(cherry picked from commit 03713f805a91749eabcfb2e23e86489b2d4034df)
Use rman_set_type to set the type of allocated resources everywhere
rman_set_rid is currently called.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44123
(cherry picked from commit 1b9bcffff39a817b77401d1b975f374781adfaf8)
Inline generic_pcie_translate_resource_common into its sole caller.
No functional change.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D44206
(cherry picked from commit 291079d0ebdd078840ccb27aaa5d286e03e2e7e6)
The generic_pcie_containing_range helper added in commit d79b6b8ec267
assumed that the passed in (start, end) range used to locate the
containing mapping range was a valid address range (with end >=
start). The previous version of
generic_pcie_translate_resource_common only used the start address to
locate a mapping range, so the end address of 0 did not matter, but an
end of 0 now causes the first range to match and an incorrect
translation for resources using a later range.
PR: 277211
Reported by: dch, tuexen
Reviewed by: tuexen
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44205
(cherry picked from commit 332dbd3a2f08a887014a425d2532af93503588ce)
Previously ranges were only enumerated for the FDT attachment but not
ACPI. This commit moves the enumeration to the shared attach routine
so it is done for both. While here, don't list empty ranges but do
include the resource type for each range.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44132
(cherry picked from commit b28670018dbcc7d6ebc0d05584189d6d04aa079f)
Unlike other bus methods updated to use bus_generic_rman_* in commit
d79b6b8ec267, the bus_release_resource method was using
bus_generic_rman_release_resource for all types other than
PCI_RES_BUS. Instead, bus_generic_rman_* should only be used for
memory and I/O port resources for this driver.
Tested by: cperciva
Reviewed by: cperciva
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D43925
(cherry picked from commit feefc3c71e33d8f97879c4889d5cf1ec82e98cd9)
Previously pci_host_generic_attach was returning 0 (success)
incorrectly if allocating a range failed. The error value was 0 from
the previously successful call to bus_set_resource in this case.
Fixes: d79b6b8ec267 pci_host_generic: Don't rewrite resource start address for translation
(cherry picked from commit 992f5b16afa73d0ea63c8a886a78ad2eda928e37)
This comment referred to the layering violation fixed in commit
b377ff8110e3489eb6e6b920b51a2384dfc4eb0b.
(cherry picked from commit 57d312b8eac9862ae60da32a9aecb6d9ccf08171)
Allocate resources from the parent device for decoded physical address
ranges. When child resources suballocated from rman's are mapped,
translate those mapping requests into a mapping request of the
associated physical address range in a bus_map_resource method.
While here, convert generic_pcie_rman to a bus_get_rman method and use
bus_generic_rman_* for operations on child resources.
Factor out a generic_pcie_containing_range to share logic between
bus_translate_resource and bus_*map_resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43894
(cherry picked from commit d79b6b8ec267e7eef6e07cf4245159705e24acd5)
Fix a long-standing layering violation in the original NEW_PCIB code
by not passing suballocated resources up to the parent bus for
activation and mapping. Instead, handle activation and mapping of
sub-allocated resources in this driver. When mapping resources,
request a mapping from a suitable sub-region of the resource allocated
from the parent bus for the associated bridge window.
Note that this does require passing RF_ACTIVE (with RF_UNMAPPED) when
allocating bridge window resources from the parent.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43690
(cherry picked from commit b377ff8110e3489eb6e6b920b51a2384dfc4eb0b)
The allocated bus numbers are in use so should be activated when
allocated.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43689
(cherry picked from commit 36efc64a6bc6318eefd9baf88cbf511e91db80c8)
Correct leading whitespace for a few lines.
Consistently use more canonical #ifdef to test for COMPAT_FREEBSD32.
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
(cherry picked from commit 727de621c5f07681034eed2d6ce3662a8239e987)
This isn't a bus driver, so an empty attach routine is more appropriate.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47220
(cherry picked from commit f2e50ce0a37a40363b7ec6a165aa0b0a2e81ffc4)
The probe routine always fails, so the attach routine is unused.
However, this weird driver is really a quirk system for PCI and should
be turned into PCI quirks instead. The Natoma quirk is also broken as
it should be doing a runtime check either on mp_ncpus (or more likely
to see if it is using APIC) instead of #ifdef.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47219
(cherry picked from commit 1cddce89ce30570d554120af864d23c554cd5d18)
Simplify the calls into the SMCCC firmware with the new
arm_smccc_invoke* macros.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D46987
(cherry picked from commit b9cd72b06d795a8c7b39df1f520e866ad7f11aa8)
In pci_host_generic_acpi.c we loop over pci_acpi_quirks to check if
we need to handle any quirks. GCC doesn't like the terminatin as it
sets a fixed width string to 0.
As this the array is only ever used in this file change to use nitems
to find when to stop the loop.
Reviewed by: brooks, imp, jhb, emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45265
(cherry picked from commit f55e866488ba2d8bb5b79659ee84bec1fe7808fb)
Allow iovctl to create VFs that are restricted to specific VLAN IDs.
Reviewed by: kib, np
MFC after: 2 weeks
Sponsored by: Orange Business Services
Differential Revision: https://reviews.freebsd.org/D45402
(cherry picked from commit c57c26179033f64c2011a2d2a904ee3fa62e826a)
These are already inherited from generic_pcie_core_driver.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43888
(cherry picked from commit 93923685d35d95e76bd2c125c007e13354b9428c)
The rman description strings now match those used in the PCI-PCI
bridge driver. Using more specific names removes ambiguity in devinfo -u
output on systems with multiple host to PCI bridges.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43890
(cherry picked from commit 51f8ac224f3b87555ea17c7e7c4015a2a2b8b191)
These functions are not used by pcib subclasses so do not need to
be exposed in pcib_private.h.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43688
(cherry picked from commit 03719c651430d46cd8aa95aead02a7f0c43dcb04)
Tell bus_dma(9) which NUMA domain the PCI driver is closest to so it
can allocate memory from there when possible.
Reviewed by: markj, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42186
(cherry picked from commit 7098f3c7569c21ecdfc990772e96a416f1a94eee)
This commit changes the API of pci_cfgreg(read|write) to add a domain
argument (referred to as a segment in ACPI parlance) (note that this
is not the same as a NUMA domain, but something PCI-specific). This
does not yet enable access to domains other than 0, but updates the
API to support domains.
Places that use hard-coded bus/slot/function addresses have been
updated to hardcode a domain of 0. A few places that have the PCI
domain (segment) available such as the acpi_pcib_acpi.c Host-PCI
bridge driver pass the PCI domain.
The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on
domain 0 since they provide APIs to their binary blobs that only
permit bus/slot/function addressing.
The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do
not support multiple domains.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42827
(cherry picked from commit 1587a9db92c03c738bb3f0fc5874b43c961e7c99)
If a parent downstream port doesn't support ARI, the code would try to
create VFs anyway but then all PCI config space access to those VFs
would fail.
Tested by: np
Approved by: re (kib)
Sponsored by: Chelsio Communications
(cherry picked from commit 7063f94283af60818429a0c2d70e80ae4ad5c146)
When remapping a MSI-X vector, we would always return ENOENT, even if
successful. This didn't really matter, as the sole caller of
BUS_REMAP_INTR also didn't check for errors.
Return 0 if there's no error, so that we can start handling (or at least
warning about) actual failures.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41449
rid was stack garbage, so the bus_alloc_resource_any() call could fail
and fall through to the SMCCC version check even if a bridge had a
memory resource.
Debugging help: jrtc27
Reviewed by: jrtc27
Fixes: c9a05c0722 Add a PCI driver that follows the Arm DEN0115 spec
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41025
