aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/pci/pci_pci.c
Commit message (Collapse)AuthorAgeFilesLines
* pcib: Clear any pending slot status events during attachJohn Baldwin2025-04-221-0/+1
| | | | | | | | | Any events left over from boot firmware, etc. are not meaningful so clear pending events during attach. If they are still pending they should remain asserted when the slot status register is re-read. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D49950
* pcib: Ignore power fault detected if a power controller is not presentJohn Baldwin2025-04-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | At least some PCI-express bridges exposed by Intel Volume Management Devices report bogus power faults in their slot status register. As a workaround, ignore the power fault detected flag if the slot capability register does not indicate support for a power controller. While the PCI-e spec does not explicitly state that the PFD flag should always be zero if a power controller is not present, parts of the spec do seem to assume this. For example, the flag is included in the "Power Controller Registers" register group in 6.7.2.4, and the definition of the value for this flag seems to presume the presence of a power controller: If a Power Controller that supports power fault detection is implemented, this bit is Set when the Power Controller detects a power fault at this slot. Note that, depending on hardware capability, it is possible that a power fault can be detected at any time, independent of the Power Controller Control setting or the occupancy of the slot. If power fault detection is not supported, this bit must not be Set. PR: 285993 Reported by: Jim Long <freebsd-bugzilla@umpquanet.com> Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D49949
* pci: Make PCIe Eject timeout configurableColin Percival2025-04-021-5/+16
| | | | | | | | | | | | | | | PCIe mandates a 5 second delay between when the "Attention Button" is pressed and when the associated device is detached; this is to allow for the button to be pressed a second time to cancel the ejection. On some systems this 5 second delay may not be desireable; so introduce a hw.pci.pcie_hp_detach_timeout sysctl (which can also be set as a loader tunable) which specifies the timeout in milliseconds (default 5000). If set to zero, the device is detached immediately. Reviewed by: jhb MFC after: 2 weeks Sponsored by: Amazon Differential Revision: https://reviews.freebsd.org/D49585
* pcib: Use taskqueue_bus for hot-plug events instead of a private taskqueueJohn Baldwin2025-03-101-18/+16
| | | | | Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D49269
* Use bus_detach_children instead of bus_generic_detachJohn Baldwin2025-01-021-1/+1
| | | | | | | These drivers perform additional teardown steps in between detaching child devices and deleting child devices. Differential Revision: https://reviews.freebsd.org/D47957
* Replace calls to bus_generic_attach with bus_attach_childrenJohn Baldwin2024-12-061-2/+3
| | | | | Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D47675
* newbus: globally replace device_add_child(..., -1) with DEVICE_UNIT_ANYWarner Losh2024-07-251-2/+2
| | | | Sponsored by: Netflix
* Retire unused non-PCI_RES_BUS codeJessica Clarke2024-07-181-60/+1
| | | | | | | | 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
* Retire non-NEW_PCIB code and remove config optionJessica Clarke2024-07-181-370/+4
| | | | | | | | | | | 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
* acpi/pci/vmd: Fix a nit with nested resource mapping requestsJohn Baldwin2024-06-041-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCEJohn Baldwin2024-03-131-4/+3
| | | | | | | | | | 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
* new-bus: Remove the 'rid' and 'type' arguments from BUS_*ACTIVATE_RESOURCEJohn Baldwin2024-03-131-10/+8
| | | | | | | | | | 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
* new-bus: Remove the 'type' argument from BUS_MAP/UNMAP_RESOURCEJohn Baldwin2024-03-131-8/+7
| | | | | | | | | | 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
* new-bus: Remove the 'type' argument from BUS_ADJUST_RESOURCEJohn Baldwin2024-03-131-4/+4
| | | | | | | | | | 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
* pcib: Use rman_get_type in internal functionsJohn Baldwin2024-03-131-12/+12
| | | | | Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44127
* sys: Set the type of allocated bus resourcesJohn Baldwin2024-03-131-0/+2
| | | | | | | | 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
* pci_pci: Remove obsolete commentJohn Baldwin2024-02-151-5/+0
| | | | | This comment referred to the layering violation fixed in commit b377ff8110e3489eb6e6b920b51a2384dfc4eb0b.
* pcib: Refine handling of resources allocated from bridge windowsJohn Baldwin2024-02-091-4/+126
| | | | | | | | | | | | | | | 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
* pcib: Allocate PCI_RES_BUS resources with RF_ACTIVEJohn Baldwin2024-02-091-2/+2
| | | | | | | | The allocated bus numbers are in use so should be activated when allocated. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D43689
* pcib: Make various bus methods private to pci_pci.cJohn Baldwin2024-02-091-5/+13
| | | | | | | | 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
* sys: Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-161-2/+0
| | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* pcib: Allocate the memory BAR with the MSI-X table.John Baldwin2023-06-191-5/+18
| | | | | | | | | | This is required for pci_alloc_msix() to work and to thus use MSI-X interrupts for PCI-e hotplug. Reported by: cperciva Reviewed by: cperciva MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D40581
* pci: Disable Electromechanical Interlock.Alexander Motin2022-10-041-1/+7
| | | | | | | | | | | | | Add sysctl/tunable to control Electromechanical Interlock support. Disable it by default since Linux does not do it either and it seems the number of systems having it broken is higher than having working. This fixes NVMe backplane operation on ASUS RS500A-E11-RS12U server with AMD EPYC 7402 CPU, where attempts to control reported interlock for some reason end up in PCIe link loss, while interlock status does not change (it is not really there). MFC after: 2 weeks
* pci: Remove unused devclass arguments to DRIVER_MODULE.John Baldwin2022-05-061-4/+1
|
* Create wrapper for Giant taken for newbusWarner Losh2021-12-101-1/+1
| | | | | | | | | | | Create a wrapper for newbus to take giant and for busses to take it too. bus_topo_lock() should be called before interacting with newbus routines and unlocked with bus_topo_unlock(). If you need the topology lock for some reason, bus_topo_mtx() will provide that. Sponsored by: Netflix Reviewed by: mav Differential Revision: https://reviews.freebsd.org/D31831
* pci_pci: Support growing bus ranges in bus_adjust_resource for NEW_PCIBJessica Clarke2021-10-031-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the same underlying problem as 262459806433, just for bus ranges rather than windows. SiFive's HiFive Unmatched has the following topology: Root Port <---> Bridge <---> Bridge <-+-> Bridge <---> (Unused) (pcib0) (pcib1) (pcib2) | (pcib3) +-> Bridge <---> xHCI | (pcib4) +-> Bridge <---> M.2 E-key | (pcib5) +-> Bridge <---> M.2 M-key | (pcib6) +-> Bridge <---> x16 slot (pcib7) If a device is plugged into the x16 slot that itself has a bridge, such as many graphics cards, we currently fail to allocate a bus number for its child bus (and so pcib_attach_child skips adding a child bus for further enumeration) as, when the new child bridge attaches, it attempts to allocate a bus number from its parent (pcib7) which in turn attempts to grow its own bus range by calling bus_adjust_resource on its own parent (pcib2) whose bus rman cannot accommodate the request and needs to itself be extended by calling its own parent (pcib1). Note that pcib3-7 do not face the same issue when they attach since pcib1 ends up managing bus numbers 1-255 from the beginning and so never needs to grow its own range. Reviewed by: jhb, mav MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D32011
* pcib(4): Switch from callout to timeout_task.Alexander Motin2021-09-031-36/+41
| | | | | | | This allows to avoid blocking on Giant in callout context, moving to already existing dedicated taskqueue_pci_hp thread. MFC after: 1 month
* pcib(4): Write window registers after resource adjustmentAlexander Motin2021-08-271-1/+11
| | | | | | | | | | | | | | | | | | When adjusting resources we should write updated window base/limit into the registers. Without this newly added address range won't be routed through the bridge properly. Use MIN()/MAX() against current window base/limit to not shrink it on the other side if the window is shared by several resources. Align passed resource start/end to the set window granularity to keep it properly aligned. Currently this is mostly called by other bridges having the same window alignment, but it may be change one day. Reviewed by: jrtc27, jhb MFC after: 1 week Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D31693
* pci_pci: Support growing windows in bus_adjust_resource for NEW_PCIBJessica Clarke2021-08-071-15/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we allocate a new window for a bridge rather than reusing an existing one set up by firmware to cover all the devices then the new window only includes the range needed for the first device to allocate the resource. If a request comes in to adjust this resource in order to extend a downstream window for another device then this will fail as the rman doesn't have any space, so we must first grow the bridge's own window. This is needed to support successfully attaching more than one PCI device on SiFive's HiFive Unmatched, which has the following topology: Root Port <---> Bridge <---> Bridge <-+-> Bridge <---> (Unused) (pcib0) (pcib1) (pcib2) | (pcib3) +-> Bridge <---> xHCI | (pcib4) +-> Bridge <---> M.2 E-key | (pcib5) +-> Bridge <---> M.2 M-key | (pcib6) +-> Bridge <---> x16 slot (pcib7) Without this, the xHCI endpoint successfully attaches but NVMe M.2 M-key endpoint fails to attach as, when its adjacent bridge (pcib6) attempts to allocate a window from its parent (pcib2) on the other side of the switch, its parent attempts to grow its own window by calling bus_adjust_resource on its own parent (pcib1) which fails to call the root port device (pcib0) to request more memory to grow its own window. Had the root port been directly connected to the switch without the bridge in the middle then the existing code would have worked, but the extra hop broke it. Reviewed by: jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D31035
* PCI hot-plug: use dedicated taskqueue for device attach / detachAndriy Gapon2021-05-061-2/+4
| | | | | | | | | | | | | | | | | | | | Attaching and detaching devices can be heavy-weight and detaching can sleep waiting for events. For that reason using the system-wide single-threaded taskqueue_thread is not really appropriate. There is even a possibility for a deadlock if taskqueue_thread is used for detaching. In fact, there is an easy to reproduce deadlock involving nvme, pass and a sudden removal of an NVMe device. A pass peripheral would not release a reference on an nvme sim until pass_shutdown_kqueue() is executed via taskqueue_thread. But the taskqueue's thread is blocked in nvme_detach() -> ... -> cam_sim_free() because of the outstanding reference. MFC after: 10 days Sponsored by: CyberSecure Reviewed by: mav, imp Differential Revision: https://reviews.freebsd.org/D30144
* pci: clean up empty lines in .c and .h filesMateusz Guzik2020-09-011-2/+1
| | | | Notes: svn path=/head/; revision=365178
* pci: loosen PCIe hot-plug requirementsChuck Tuffli2020-06-101-9/+1
| | | | | | | | | | | | | | | | | | | | | The original PCIe hot-plug code required a couple of things which cause PCI probing errors on the QEMU Q35 system and possibly physical systems (Dell R6515). Allocate the hot-plug interrupt as shared to support INTx interrupts. The hot-plug interrupt mechanism should normally be MSI as PCIe mandates MSI support, but QEMU's Q35 bridge only provides INTx interrupts. Second, the code required the Electromechanical Interlock (Slot Status EIS) to be engaged if present (Slot Capability EIP). Some platforms including QEMU Q35 set EIP but not EIS. Fix by deleting the check. Reviewed by: imp, mav, jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24877 Notes: svn path=/head/; revision=362027
* do not enable pci bridge decoding on resume until I/O windows are restoredAndriy Gapon2020-05-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PCI bus driver restores most but not all of a child PCI-PCI bridge configuration. The bridge's I/O windows are restored by pcib driver and that happens later in time. This can be problematic because the Command register is restored before the windows are restored. If the firmware programs the windows incorrectly or even does not program them at all, then the bridge can start claiming I/O cycles that are not intended for it. This will continue until the correct windows are restored. I have observed this problem with a buggy BIOS where after resuming from S3 an I/O port window of a PCI-PCI bridge was configured with zero base and limit causing the bridge to claim 0x0 - 0xFFF port range. That interfered with ACPI port access including ACPI PM Timer at port 0x808, thus wreaking havoc in the time keeping. The solution is to restore the Command register of PCI-PCI bridges after the windows are restored in pcib driver. While here, I decided that for other PCI device types (normal and cardbus) it's better to restore the Command register after their BARs are restored. To do: per jhb's suggestion, move the window handling to pci driver. Reviewed by: imp, jhb, kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25028 Notes: svn path=/head/; revision=361621
* Abstract the locking for PCIe hotplug. It still uses Giant so there'sScott Long2019-12-261-6/+9
| | | | | | | no functional change yet. Notes: svn path=/head/; revision=356098
* Don't consider PCIe hot-plug command timeout fatal.Alexander Motin2019-08-261-5/+2
| | | | | | | | | | | | | | | | | According to my tests and errata to several generations of Intel CPUs, PCIe hot-plug command completion reporting is not very reliable thing. At least on my Supermicro X11DPi-NT board I never saw it reported. Before this change timeout code detached devices and tried to disable the slot, that in my case resulted in hot-plugged device being detached just a second after it was successfully detected and attached. This change removes that, so in case of timeout it just prints the error and continue operation. Linux does the same. MFC after: 1 week Sponsored by: iXsystems, Inc. Notes: svn path=/head/; revision=351514
* Only respond to the PCIe Attention Button if a device is already plugged in.Colin Percival2019-06-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this commit, if PCIEM_SLOT_STA_ABP and PCIEM_SLOT_STA_PDC are asserted simultaneously, FreeBSD sets a 5 second "hardware going away" timer and then processes the "presence detect" change. In the (physically challenging) case that someone presses the "attention button" and inserts a new PCIe device at exactly the same moment, this results in FreeBSD recognizing that the device is present, attaching it, and then detaching it 5 seconds later. On EC2 "bare metal" hardware this is the precise sequence of events which takes place when a new EBS volume is attached; virtual machines have no difficulty effecting physically implausible simultaneity. This patch changes the handling of PCIEM_SLOT_STA_ABP to only detach a device if the presence of a device was detected *before* the interrupt which reports the Attention Button push. Reported by: Matt Wilson Reviewed by: jhb MFC after: 1 week Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D20499 Notes: svn path=/head/; revision=348681
* Extract eventfilter declarations to sys/_eventfilter.hConrad Meyer2019-05-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h" in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header pollution substantially. EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c files into appropriate headers (e.g., sys/proc.h, powernv/opal.h). As a side effect of reduced header pollution, many .c files and headers no longer contain needed definitions. The remainder of the patch addresses adding appropriate includes to fix those files. LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by sys/mutex.h since r326106 (but silently protected by header pollution prior to this change). No functional change (intended). Of course, any out of tree modules that relied on header pollution for sys/eventhandler.h, sys/lock.h, or sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped. Notes: svn path=/head/; revision=347984
* Implement resets for PCI buses and PCIe bridges.Konstantin Belousov2019-04-051-0/+31
| | | | | | | | | | | | | | | | | For PCI device (i.e. child of a PCI bus), reset tries FLR if implemented and worked, and falls to power reset otherwise. For PCIe bus (child of a PCIe bridge or root port), reset disables PCIe link and then re-trains it, performing what is known as link-level reset. Reviewed by: imp (previous version), jhb (previous version) Sponsored by: Mellanox Technologies MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D19646 Notes: svn path=/head/; revision=345963
* Sprinkle EARLY_DRIVER_MODULE around the treeJustin Hibbits2018-12-041-1/+2
| | | | | | | | | | | | | | | | Mark some buses as BUS_PASS_BUS, and some resources as BUS_PASS_RESOURCE. This also decouples some resource attachment orderings from being races by device tree ordering, instead relying on the bus pass to provide the ordering. This was originally intended to support multipass suspend/resume, but it's also needed on PowerMacs when using fdt, as the device tree seems to get created in reverse of the OFW tree. Reviewed by: nwhitehorn (long ago) Differential Revision: https://reviews.freebsd.org/D918 Notes: svn path=/head/; revision=341455
* Only conform to PCIe spec of 1 device per bus on !x86Justin Hibbits2018-05-301-0/+2
| | | | | | | | | | bhyve's root PCI complex shows up as PCIe, but behaves as traditional PCI. Until that is special cased in a root complex driver, leave x86 as it was. Requested by: grehan Notes: svn path=/head/; revision=334407
* Restrict PCIe maxslots to 0, instead of PCI_SLOTMAXJustin Hibbits2018-05-301-1/+15
| | | | | | | | | | | | | | | | | Summary: PCIe only permits 1 device on an endpoint, so some devices ignore the device part of B:D:F probing. Although ARI likely fixes this, not all platforms support ARI completely or correctly, so some devices end up showing up 32 times on the bus. This was found during bringup of POWER9/Talos, and has been tested on POWER9 and POWER8 hardware. Reviewed by: leitao Differential Revision: https://reviews.freebsd.org/D15461 Notes: svn path=/head/; revision=334365
* Do pass removing some write-only variables from the kernel.Alexander Kabaev2017-12-251-5/+1
| | | | | | | | | | | | This reduces noise when kernel is compiled by newer GCC versions, such as one used by external toolchain ports. Reviewed by: kib, andrew(sys/arm and sys/arm64), emaste(partial), erj(partial) Reviewed by: jhb (sys/dev/pci/* sys/kern/vfs_aio.c and sys/kern/kern_synch.c) Differential Revision: https://reviews.freebsd.org/D10385 Notes: svn path=/head/; revision=327173
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326255
* Various fixes for PCI _OSC handling so HotPlug works again.John Baldwin2017-04-271-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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 Notes: svn path=/head/; revision=317510
* Fix spelling mistake in comment, firmwrae -> firmwareGavin Atkinson2017-02-281-1/+1
| | | | Notes: svn path=/head/; revision=314437
* Convert PCIe Hot Plug to using pci_request_featureWarner Losh2017-02-251-0/+30
| | | | | | | | | | | | Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix Notes: svn path=/head/; revision=314250
* Rename pci_pcie_intr to pci_pcie_intr_hotplug.Warner Losh2017-02-251-4/+4
| | | | | | | Sponsored by: Netflix Notes: svn path=/head/; revision=314249
* Create pcib_request_feature.Warner Losh2017-02-251-0/+24
| | | | | | | | | | | | pcib_request_feature allows drivers to request the firmware (ACPI) release certain features it may be using. ACPI normally manages things like hot plug, advanced error reporting and other features until the OS requests ACPI to relenquish control since it is taking over. Sponsored by: Netflix Notes: svn path=/head/; revision=314248
* PCIe HotPlug: remove tests for DL active link capabilityEric van Gyzen2017-02-041-25/+19
| | | | | | | | | | | | | | | As of r313097, the HotPlug code requires the link to support reporting of the data-link status. Remove tests for this capability from code that can now assume its presence. Suggested by: jhb Reviewed by: jhb MFC after: 3 days Sponsored by: Dell EMC Differential Revision: https://reviews.freebsd.org/D9431 Notes: svn path=/head/; revision=313180
* Require Data Layer Active reporting for native PCI-e HotPlug.John Baldwin2017-02-021-0/+2
| | | | | | | | | | | | | | | | | | | Some PCI-e bridges report that they support HotPlug in the slot capabilities but do not report support for Data Layer Active events in the link capabilities register. These bridges do not work correctly when HotPlug is used. Further, while the description of HotPlug in the spec does not mention that DL active events are required, the description of the link capabilities register says that DL active is required for HotPlug. Thanks to Dave Baukus for finding that language in the spec. PR: 211699 Submitted by: Dave Baukus <daveb@spectralogic.com> Reviewed by: vangyzen MFC after: 3 days Notes: svn path=/head/; revision=313097
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 16:55:21 +0000