acpi: Pass the correct device to acpi_pcib_osc

Fix a copy-and-paste error in acpi_pcib_request_feature where the
child device was passed into acpi_pcib_osc rather than the pcib
device.

Reviewed by:

acpi: Pass the correct device to acpi_pcib_osc

Fix a copy-and-paste error in acpi_pcib_request_feature where the
child device was passed into acpi_pcib_osc rather than the pcib
device.

Reviewed by: garga, jhb
Fixes: ba1904937d9a ("acpica: Extract _OSC parsing to a common file")
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48285

show more ...

acpica: Extract _OSC parsing to a common file

This will be used by pci_host_generic_acpi.c so needs to be in a
common location.

Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: ht

acpica: Extract _OSC parsing to a common file

This will be used by pci_host_generic_acpi.c so needs to be in a
common location.

Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48044

show more ...

Replace calls to bus_generic_attach with bus_attach_children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47675

Replace calls to bus_generic_probe with bus_identify_children

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D47674

Retire unused non-PCI_RES_BUS code

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
Different

Retire unused non-PCI_RES_BUS code

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

show more ...

Retire non-NEW_PCIB code and remove config option

All architectures enable NEW_PCIB in DEFAULTS (arm being the most recent
to do so in 121be555997b (arm: Set NEW_PCIB in DEFAULTS rather than a
subse

Retire non-NEW_PCIB code and remove config option

All architectures enable NEW_PCIB in DEFAULTS (arm being the most recent
to do so in 121be555997b (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

show more ...

new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE

The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.

new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE

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

show more ...

new-bus: Remove the 'rid' and 'type' arguments from BUS_*ACTIVATE_RESOURCE

The public bus_activate/deactivate_resource() API still accepts both
forms, but the internal kobj methods no longer pass th

new-bus: Remove the 'rid' and 'type' arguments from BUS_*ACTIVATE_RESOURCE

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

show more ...

new-bus: Remove the 'type' argument from BUS_ADJUST_RESOURCE

The public bus_adjust_resource() API still accepts both forms, but the
internal kobj method no longer passes the argument. Implementatio

new-bus: Remove the 'type' argument from BUS_ADJUST_RESOURCE

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

show more ...

acpi_pcib: Use pci_domain_[de]activate_bus for PCI_RES_BUS resources

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43428

pci_cfgreg: Add a PCI domain argument to the low-level register API

This commit changes the API of pci_cfgreg(read|write) to add a domain
argument (referred to as a segment in ACPI parlance) (note t

pci_cfgreg: Add a PCI domain argument to the low-level register API

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

show more ...

acpi_pcib: Rename decoded_bus_range to get_decoded_bus_range

While here, change the return value to bool.

Discussed by: gibbs

acpi_pcib: Trust decoded bus range from _CRS over _BBN

Currently if _BBN doesn't match the first bus in the decoded bus range
from _CRS for a Host to PCI bridge, the driver fails to attach as a
defe

acpi_pcib: Trust decoded bus range from _CRS over _BBN

Currently if _BBN doesn't match the first bus in the decoded bus range
from _CRS for a Host to PCI bridge, the driver fails to attach as a
defensive measure.

There is now firmware in the field where these do not match, and the
_BBN values are clearly wrong, so rather than failing attach, trust
the range from _CRS over _BBN.

Co-authored-by: Justin Gibbs <gibbs@FreeBSD.org>
Reported by: gibbs
Reviewed by: imp (earlier version)
Differential Revision: https://reviews.freebsd.org/D42231

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

acpica: do not print warning for missing _ADR

Started seeing the following after updating to VMware ESXi 8.0:

pcib2: <ACPI Host-PCI bridge> on acpi0
pcib2: could not evaluate _ADR - AE_NOT_FOUND
pc

acpica: do not print warning for missing _ADR

Started seeing the following after updating to VMware ESXi 8.0:

pcib2: <ACPI Host-PCI bridge> on acpi0
pcib2: could not evaluate _ADR - AE_NOT_FOUND
pci2: <ACPI PCI bus> on pcib2
vmx0: <VMware VMXNET3 Ethernet Adapter> ...

The virtual NIC works fine, and the code comment suggests that
missing _ADR is not something fatal, skip printing the message
if status is AE_NOT_FOUND.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/682

show more ...

acpi: Remove unused devclass arguments to DRIVER_MODULE.

Add mostly dummy hw.pci.enable_aspm tunable.

The only thing this tunable enables now is reporting to ACPI _OSC that
Active State Power Management and Clock Power Management Capability are
"supported

Add mostly dummy hw.pci.enable_aspm tunable.

The only thing this tunable enables now is reporting to ACPI _OSC that
Active State Power Management and Clock Power Management Capability are
"supported" by the OS.

I've found that at least some Supermicro server boards do not allow OS
to support native PCIe hot-plug unless it reports those capabilities.
After spending significant time in PCIe specs I have found very little
motivation for that, and none of it applies to those motherboards, not
enabling ASPM themselves. So unless OS explicitly wants to save power,
I see nothing for it to do there actually.

I guess it may get sense to support ASPM when we get Thunderbolt support.
Otherwise I have no system with PCIe hot-plug where power saving matters.

It would be nice to enable this by default, but I worry that it affect
power saving of some laptops, even though I haven't noticed that myself.

show more ...

Merge ^/head r351317 through r351731.

Announce PCI Segment Groups supported to PCI host _OSC.

According to ACPI 6.3 specification:
The OS sets this bit to 1 if it supports PCI Segment Groups as defined
by the _SEG object, and ac

Announce PCI Segment Groups supported to PCI host _OSC.

According to ACPI 6.3 specification:
The OS sets this bit to 1 if it supports PCI Segment Groups as defined
by the _SEG object, and access to the configuration space of devices
in PCI Segment Groups as described by this specification. Otherwise,
the OS sets this bit to 0.

As far as I see we support both of those as PCI domains for quite a while.

MFC after: 2 months

show more ...

Merge ^/head r327886 through r327930.

Add support for NUMA domains to bus dma tags. This causes all memory
allocated with a tag to come from the specified domain if it meets the
other constraints provided by the tag. Automatically crea

Add support for NUMA domains to bus dma tags. This causes all memory
allocated with a tag to come from the specified domain if it meets the
other constraints provided by the tag. Automatically create a tag at
the root of each bus specifying the domain local to that bus if
available.

Reviewed by: jhb, kib
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13545

show more ...

Merge ^/head r317971 through r318379.

hyperv/vmbus: Reorganize vmbus device tree

For GEN1 Hyper-V, vmbus is attached to pcib0, which contains the
resources for PCI passthrough and SR-IOV. There is no
acpi_syscontainer0 on GEN1 Hyper-V.

hyperv/vmbus: Reorganize vmbus device tree

For GEN1 Hyper-V, vmbus is attached to pcib0, which contains the
resources for PCI passthrough and SR-IOV. There is no
acpi_syscontainer0 on GEN1 Hyper-V.

For GEN2 Hyper-V, vmbus is attached to acpi_syscontainer0, which
contains the resources for PCI passthrough and SR-IOV. There is
no pcib0 on GEN2 Hyper-V.

The ACPI VMBUS device now only holds its _CRS, which is empty as
of this commit; its existence is mainly for upward compatibility.

Device tree structure is suggested by jhb@.

Tested-by: dexuan@
Collabrated-wth: dexuan@
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D10565

show more ...

Merge ^/head r317503 through r317807.

Various fixes for PCI _OSC handling so HotPlug works again.

- Rename the default implementation of 'pcib_request_feature' and add
a pcib_request_feature() wrapper function (as is often done for

Various fixes for PCI _OSC handling so HotPlug works again.

- Rename the default implementation of 'pcib_request_feature' and add
a pcib_request_feature() wrapper function (as is often done for
new-bus APIs implemented via kobj) that accepts a single function.
Previously the call to pcib_request_feature() ended up invoking the
method on the great-great-grandparent of the bridge device instead
of the grandparent. For a bridge that was a direct child of pci0 on
x86 this resulted in the method skipping over the Host-PCI bridge
driver and being invoked against nexus0
- When invoking _OSC from a Host-PCI bridge driver, invoke
device_get_softc() against the Host-PCI bridge device instead of the
child bridge that is requesting HotPlug. Using the wrong softc data
resulted in garbage being passed for the ACPI handle causing the
_OSC call to fail.
- While here, perform some other cleanups to _OSC handling in the ACPI
Host-PCI bridge driver:
- Don't invoke _OSC when requesting a control that has already been
granted by the firmware.
- Don't set the first word of the capability array before invoking
_OSC. This word is always set explicitly by acpi_EvaluateOSC()
since it is UUID-independent.
- Don't modify the set of granted controls unless _OSC doesn't exist
(which is treated as always successful), or the _OSC method
doesn't fail.
- Don't require an _OSC status of 0 for success. _OSC always
returns the updated control mask even if it returns a non-zero
status in the first word.
- Whine if _OSC ever tries to revoke a previously-granted control.
(It is not supposed to do that.)
- While here, add constants for the _OSC status word in acpivar.h
(though currently unused).

Reported by: adrian
Reviewed by: imp
MFC after: 1 week
Tested on: Lenovo x220
Differential Revision: https://reviews.freebsd.org/D10520

show more ...