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
These drivers perform additional teardown steps in between detaching
child devices and deleting child devices.
Differential Revision: https://reviews.freebsd.org/D47957
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.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D43921
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
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
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
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
Correct leading whitespace for a few lines.
Consistently use more canonical #ifdef to test for COMPAT_FREEBSD32.
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
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
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
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
The pre-freebsd7 stuff is labeled _old right now. Relabel it as
_freebsd6 instead. No functional change intended. I selected freebsd6
because that's the last version to have the ioctls, although I know
there were changes in the interface for 4, 5 and 6. This broadly batches
what we do with system calls that accumulate changes until we break and
use a new one, we use the last major the system call was in.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D45867
All architectures define PCI_RES_BUS unconditionally now that only
NEW_PCIB is supported, so we no longer need the legacy code.
Reviewed by: jhb, andrew
Differential Revision: https://reviews.freebsd.org/D32955
All architectures enable NEW_PCIB in DEFAULTS (arm being the most recent
to do so in 121be55599 (arm: Set NEW_PCIB in DEFAULTS rather than a
subset of kernel configs")), so it's time we removed the legacy code
that no longer sees much testing and has a significant maintenance
burden.
Reviewed by: jhb, andrew, emaste
Differential Revision: https://reviews.freebsd.org/D32954
On read error, we would return -1, but not handle it, causing a zero
size malloc of value, and then we wouldd unconditionally write
value[-1 + 1] = '\0'. This should be harmless in terms of buffer
overflow because we should get a minimum non-zero size allocation from
malloc, but it also effectively swallowed the error.
Reported by: GCC -Wstringop-overflow
Reviewed by: kib, se
Differential Revision: https://reviews.freebsd.org/D45895
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
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: 871b33ad65 pci: Consistently use pci_vf_* for suballocated VF memory resources
Differential Revision: https://reviews.freebsd.org/D45499
`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: 98056127dd ("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
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
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: 0e1246e334 acpi: Cleanup handling of suballocated resources
Fixes: b377ff8110 pcib: Refine handling of resources allocated from bridge windows
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Fixes: d714e73f78 vmd: Use bus_generic_rman_* for PCI bus and memory resources
Differential Revision: https://reviews.freebsd.org/D45433
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
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: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44698
The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44131
The public bus_activate/deactivate_resource() API still accepts both
forms, but the internal kobj methods no longer pass the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44130
The public bus_map/unmap_resource() API still accepts both forms, but
the internal kobj methods no longer pass the argument.
Implementations which need the type now use rman_get_type() to fetch
the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44129
The public bus_adjust_resource() API still accepts both forms, but the
internal kobj method no longer passes the argument. Implementations
which need the type now use rman_get_type() to fetch the value from
the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44128
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
Inline generic_pcie_translate_resource_common into its sole caller.
No functional change.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D44206
The generic_pcie_containing_range helper added in commit d79b6b8ec2
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: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44205
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
Unlike other bus methods updated to use bus_generic_rman_* in commit
d79b6b8ec2, 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: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D43925
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: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
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
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
