pci: Only add special VF handling for direct children in bus methods

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

pci: Consistently use pci_vf_* for suballocated VF memory resources

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

pci: Use kobj typedefs for new-bus method prototypes

Reviewed by: kp, imp
Differential Revision: https://reviews.freebsd.org/D45405

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

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

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

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

pci: return 0 for pci_remap_intr_method MSI-X non-error case

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

dev/pci: simplify PCI VPD access functions

This update contains a rewrite of the VPD parser based on the
definition of the structure of the VPD data (ident, R/O resource
data, optional R/W data, end tag).

The parser it replaces was based on a state machine, with the tags
and the parsed data controlling the state changes. The flexibility
of this parser is actually not required, and it has caused kernel
panics when operating on malformed data.

Analysis of the VPD code to make it more robust lead me to believe
that it was easier to write a "strict" parser than to restrict the
flexible state machine to detect and reject non-well-formed data.
A number of restrictions had already been added, but they make the
state machine ever more complex and harder to understand.

This updated parser has been verified to return identical parsed data
as the current implementation for the example VPD data given in the
PCI standard and in some actual PCIe VPD data.

It is strict in the sense that it detects and rejects any deviation
from a well-formed VPD structure.

PR: 272018
Approved by: kib
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D34268

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

pci: add tunable hw.pci.enable_mps_tune

If the tunable is set to 0, the tuning of the MPS (maximum payload size)
is disabled and the default MPS values set by the BIOS are used. In this
case the system may use a lower speed or operate in a less optimized
state, but it can resolve issues with stability and compatibility. With
specific devices the tuning of the mps, can lead to a complete freeze of
the system.

Reviewed by: manu
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38397

pci(4): Fix a typo in asource code comment

- s/overriden/overridden/

MFC after: 3 days

pci: Add helper routines to iterate over a device's BARs.

Reviewed by: imp, markj, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36237

ddb: annotate some commands with DB_CMD_MEMSAFE

This is not completely exhaustive, but covers a large majority of
commands in the tree.

Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35583

pci(4): Fix a common typo in source code comments

- s/transistions/transitions/

MFC after: 3 days

pci: Remove unused devclass arguments to DRIVER_MODULE.

pci: recognize "non-essential instrumentation" devices

Some AMD EPYC VCPUs generated boot message of the type:

pci4: <unknown> at device 0.0 (no driver attached)

These are displayed for device class 0x13 devices, e.g.:

none8@pci0:130:0:0: class=0x130000 rev=0x00 hdr=0x00 vendor=0x1022 \
device=0x148a subvendor=0x1022 subdevice=0x148a
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Starship/Matisse PCIe Dummy Function'
class = non-essential instrumentation

Since these devices serve no purpose (no driver attaches) I have
enabled the reporting of suich devices only for verbose boots (a
diversion from the patch provided in the PR).

A verbose boot will now display such devices as:

pci4: <non-essential instrumentation> at device 0.0 (no driver attached)

PR: 263469
Reported by: jfc@mit.edu (John F. Carr)
MFC after: 1 week

Mark cfg as __unused to avoid ifdef soup

Sponsored by: Netflix

pci: Add arbitrary locator support to pci.

If the pciX:Y:Z and pciW:X:Y:Z 'at' locations don't work, allow try the
LOCATOR:PATH syntax. Use dev_wired_cache to generically look them up.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32784

pci: switch logic a little

If we find a match, then assign it. Flip the logic in the if and assign
the unit rather than continuing if it doesn't match. Will make it easier
to expand to other matching schemes.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32779

Add UEFI locator for bus_get_device_path, pci acpi

Add a UEFI locator type. It prints the UEFI device names for a FreeBSD
device_t name. It works with PCI and ACPI device nodes. USB forthcoming.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32749

dev/pci: fix potential panic due to bogus VPD data

A panic has been observed on a system with a Intel X520 dual LAN
device. The panic is caused by a KASSERT() noticing that the amount
of VPD data copied out to the pciconf command does not match the
amount of data read from the device.

The cause of the size mismatch was VPD data that started with 0x82,
the VPD tag that indicates that a VPD ident follows, but with a length
of more than 255 characters, which happens to be the maximum ident
size supported by the API between kernel and the pciconf program.
The data provided did not resemble an actual VPD identifier, and it
can be assumed that the initial tag value 0x82 happens to be there
by accident.

An ident size of 255 far exceeds the sensible length of that data
element, which is in the order of at most 30 to 40 bytes.

This patch adds several consitstency checks to the VPD parser, the
most critical being that ident lengths of more than 255 bytes are
rejected. Other checks reject VPD with more than one ident tag or
with an empty (zero length) ident string.

This patch prevents the panic that occured when "pciconf -lV" was
executed on the affected system.

During the anaylsis of the issue and the VPD code it has been
found that the VPD parser uses a state machine that accepts tags
in any order and combination. This is a bad match for the actual
VPD data, which has a very simple structure that can be parsed
with a non-recursive direct descent parser (which always knows
exactly which token to expect next).

A review fpr a much simpler VPD parser that performs many more
consistency checks and rejects invalid VPD has been proposed in
review https://reviews.freebsd.org/D34268.

Reported by: mikej at paymentallianceintl.com (Michael Jung)
Approved by: jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34255

pci: Don't try to read cfg registers of non-existing devices

Instead of returning 0xffs some controllers, such as Layerscape generate
an external exception when someone attempts to read any register
of config space of a non-existing device other than PCIR_VENDOR.
This causes a kernel panic.
Fix it by bailing during device enumeration if a device vendor register
returns invalid value. (0xffff)
Use this opportunity to replace some hardcoded values with a macro.

I believe that this change won't have any unintended side-effects since
it is safe to assume that vendor == 0xffff -> hdr_type == 0xffff.

Sponsored by: Alstom
Obtained from: Semihalf
Reviewed by: jhb
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D33059

pci: Implement pci_bar_enabled() for SR-IOV VFs

In a VF's configuration space, "memory space enable" is hard-wired to 0,
so the existing implementation always returns false. We need to read
the SR-IOV control register from the PF device to get the value of the
MSE bit.

Fix pci_bar_enabled() to read this register instead for VFs. I don't
see any way to access the PF's config space without a backpointer in the
pci device ivars, so I added one.

This fixes a regression where bhyve(8) fails to map the MSI-X table
after commit 7fa233534736 ("bhyve: Map the MSI-X table unconditionally
for passthrough") when a VF is passed through, since with that commit we
use PCIOCBARMMAP to map the table and that ioctl always fails for VFs
without this change. As a bonus, pciconf(8) now correctly reports the
enablement of BARs for VFs.

Reported and tested by: Raúl Muñoz <raul.munoz@custos.es>
Reviewed by: rstone, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32839

LinuxKPI: Support lazy BAR allocation

Linux KPIs like pci_resource_start/len assume that BARs have been
allocated, but FreeBSD lazily allocates BARs if it cannot allocate the
firmware-allocated BARs. Thus using the Linux KPIs must force allocation
of the BARs rather than returning 0 for the start and length, which can
crash drm-kmod drivers that assume the BARs are valid. This is needed
for the AMDGPU driver to be able to attach on SiFive's HiFive Unmatched.

Reviewed by: hselasky, jhb, mav
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32447

newbus: Move from bus_child_{pnpinfo,location}_src to bus_child_{pnpinfo,location} with sbuf

Now that the upper layers all go through a layer to tie into these
information functions that translates an sbuf into char * and len. The
current interface suffers issues of what to do in cases of truncation,
etc. Instead, migrate all these functions to using struct sbuf and these
issues go away. The caller is also in charge of any memory allocation
and/or expansion that's needed during this process.

Create a bus_generic_child_{pnpinfo,location} and make it default. It
just returns success. This is for those busses that have no information
for these items. Migrate the now-empty routines to using this as
appropriate.

Document these new interfaces with man pages, and oversight from before.

Reviewed by: jhb, bcr
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D29937

Set PCIe device's Max_Payload_Size to match PCIe root's.

Usually on boot the MPS is already configured by BIOS. But we've
found that on hot-plug it is not true at least for our Supermicro
X11 boards. As result, mismatch between root's configuration of
256 bytes and device's default of 128 bytes cause problems for some
devices, while others seem to work fine.

MFC after: 1 month
Sponsored by: iXsystems, Inc.

pci: enhance printf for leaked MSI[-X] vectors

When debugging leaked MSI/MSI-X vectors through LinuxKPI I found
the informational printf unhelpful. Rather than just stating we
leaked also tell how many MSI or MSI-X vectors we leak.

Sponsored-by: The FreeBSD Foundation
Reviewed-by: jhb
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D29394

Implement pci_get_relaxed_ordering_enabled() helper function.

Discussed with: kib@
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

pci: Add pci_find_class_from

pci_find_class_from help finding one or multiple device matching
a class and subclass.
If the from argument is not null we will first loop in the device list
until we find the matching device and only then start to check if the
class/subclass matches.

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D27549

Rename kernel option ACPI_DMAR to IOMMU.
This is mostly needed for a common arm64/amd64 iommu code.

Reviewed by: kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D26587

o Rename acpi_iommu_get_dma_tag() -> iommu_get_dma_tag().
This function isn't ACPI dependent and we may use it on FDT systems
as well.
o Don't repeat the function declaration, include iommu.h instead.

Reviewed by: andrew, kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D26584

pci: clean up empty lines in .c and .h files

Enable hw.pci.enable_aspm tunable by default.

While effects on power saving is only a guess, effects on hot-plug are
clearly visible. Lets try to enable it and see what happen.

MFC after: 3 months

Add initial driver for ACPI Platform Error Interfaces.

APEI allows platform to report different kinds of errors to OS in several
ways. We've found that Supermicro X10/X11 motherboards report PCIe errors
appearing on hot-unplug via this interface using NMI. Without respective
driver it ended up in kernel panic without any additional information.

This driver introduces support for the APEI Generic Hardware Error Source
reporting via NMI, SCI or polling. It decodes the reported errors and
either pass them to pci(4) for processing or just logs otherwise. Errors
marked as fatal still end up in kernel panic, but some more informative.

When somebody get to native PCIe AER support implementation both of the
reporting mechanisms should get common error recovery code. Since in our
case errors happen when the device is already gone, there is nothing to
recover, so the code just clears the error statuses, practically ignoring
the otherwise destructive NMIs in nicer way.

MFC after: 2 weeks
Relnotes: yes
Sponsored by: iXsystems, Inc.

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.

do not enable pci bridge decoding on resume until I/O windows are restored

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

Rename dmar_get_dma_tag() to acpi_iommu_get_dma_tag().
This is needed for a new IOMMU controller support.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D24943

Remove spurious warning about invalid VPD data.

The warning used to be displayed for valid VPDs about 512B or above in
size. Fix the size check and add a break while here so that the routine
stops if if detects any problem.

Tested with "pciconf -lV"

Reviewed by: kib@, jhb@
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D23679

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (5 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked). Use it in
preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Reviewed by: imp, kib
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D23633

Remove VMware MSI-X from the PCI blacklist.

First reported against ESXi 5.0, PCI passthrough was not working due to
MSI-X issues. However, this issue was fixed via patch releases against
ESXi 5.5 and 6.0 in 2016. Given ESXi 5.5 and earlier have been EOL, this
patch removes the VMware MSI-X blacklist entries in the quirk table.

PR: 203874
Reviewed by: imp, jhb
MFC after: 1 month
Sponsored by: VMware
Differential Revision: https://reviews.freebsd.org/D22819

Hoist locking giant back up into the ioctl handler

Move the locking back into the ioctl handler. This "fixes" the race where we hve
a hot plug event just after the dropping of Giant in pci_find_dbsf, assuming the
driver doesn't then call anything that drops and picks up Giant again... It's a
little safer since don't think it doesn't, but we lack the tools to know for
sure.

Push Giant down one layer

The /dev/pci device doesn't need GIANT, per se. However, one routine
that it calls, pci_find_dbsf implicitly does. It walks a list that can
change when PCI scans a new bus. With hotplug, this means we could
have a race with that scanning. To prevent that, take out Giant around
scanning the list.

However, given that we have places in the tree that drop giant, if
held when we call into them, the whole use of Giant to protect newbus
may be less effective that we desire, so add a comment about why we're
talking it out, and we'll address the issue when we lock newbus with
something other than Giant.

Export pci_attach() and pci_detach().

Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21948

Work around devices which return all zeros for reads of existing MSI-X
table VCTRL registers.

Unconditionally program the MSI-X vector control Mask field for MSI-X
table entries without regarud for Mask's previous value. Some devices
return all zeros on reads of the VCTRL registers, which would cause us
to skip disabling interrupts. This fixes the Samsung SM961/PM961 SSDs
which are return zero starting from offset 0x3084 within the memory
region specified by BAR0, even when they are active MSI-X vectors.

The Illumos kernel writes these unconditionally to 0 or 1. However,
section 6.8.2.9 of the PCI Local Bus 3.0 spec (dated Feb 3, 2004)
states for bits 31::01:
After reset, the state of these bits must be 0. However, for
potential future use, software must preserve the value of
these reserved bits when modifying the value of other Vector
Control bits. If software modifies the value of these reserved
bits, the result is undefined."
so we always set or clear the Mask bit, but otherwise preserves the
old value.

PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713
Reviewed By: imp, jhb
Submitted by: Ka Ho Ng
MFC After: 1 week
Differential Revision: https://reviews.freebsd.org/D20873

Extract eventfilter declarations to sys/_eventfilter.h

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.

remove the 4GB boundary requirement on PCI DMA segments

Reviewed by: kib
Discussed with: jhb
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D19867

Give new home to the comment from ppt_pci_reset(), explaining a nuance
of power reset.

Noted by: soralx@cydem.org
Sponsored by: Mellanox Technologies
MFC after: 12 days

Implement resets for PCI buses and PCIe bridges.

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

Devices behind downstream bridges should still get DMAR protection.

Reviewed by: kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D19717

Enable PCI BAR reallocation by default.

When pci_realloc_bars was first added, the intention was to eventually
enable it by default, but it was left disabled to preserve existing
behavior. The setting is pretty conservative in that it does not
attempt to allocate resources for BARs that the BIOS/firmware leaves
disabled. It only attempts to reallocate resources for a BAR that the
firmware programmed during boot but that conflicts with another
resource during the kernel's device scan.

PR 221350 is an example of a machine that this knob fixes.

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

add support for marking interrupt handlers as suspended

The goal of this change is to fix a problem with PCI shared interrupts
during suspend and resume.

I have observed a couple of variations of the following scenario.
Devices A and B are on the same PCI bus and share the same interrupt.
Device A's driver is suspended first and the device is powered down.
Device B generates an interrupt. Interrupt handlers of both drivers are
called. Device A's interrupt handler accesses registers of the powered
down device and gets back bogus values (I assume all 0xff). That data is
interpreted as interrupt status bits, etc. So, the interrupt handler
gets confused and may produce some noise or enter an infinite loop, etc.

This change affects only PCI devices. The pci(4) bus driver marks a
child's interrupt handler as suspended after the child's suspend method
is called and before the device is powered down. This is done only for
traditional PCI interrupts, because only they can be shared.

At the moment the change is only for x86.

Notable changes in core subsystems / interfaces:
- BUS_SUSPEND_INTR and BUS_RESUME_INTR methods are added to bus
interface along with convenience functions bus_suspend_intr and
bus_resume_intr;
- rman_set_irq_cookie and rman_get_irq_cookie functions are added to
provide a way to associate an interrupt resource with an interrupt
cookie;
- intr_event_suspend_handler and intr_event_resume_handler functions
are added to the MI interrupt handler interface.

I added two new interrupt handler flags, IH_SUSP and IH_CHANGED, to
implement the new intr_event functions. IH_SUSP marks a suspended
interrupt handler. IH_CHANGED is used to implement a barrier that
ensures that a change to the interrupt handler's state is visible
to future interrupts.
While there, I fixed some whitespace issues in comments and changed a
couple of logically boolean variables to be bool.

MFC after: 1 month (maybe)
Differential Revision: https://reviews.freebsd.org/D15755

Work around BIOS quirks on HPE Proliant MicroServer Gen10

PR: 221350
Submitted by: Bob Bishop
Reported by: Rafal Lukawiecki
Reviewed by: jhb
MFC after: 2 weeks

Sprinkle EARLY_DRIVER_MODULE around the tree

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

Rudimentary AER reading code for ddb(4).

This is very primitive code to inspect the PCI error state and AER
error state, dump the log and clear errors, from ddb.
pci_print_faulted_dev() is made external to allow calling it from
other places. It was called from NMI handler but this chunk is not
included.

Also there is a tunable-controlled code to clear AER on device attach,
disabled by default.

All this code was useful to me when I debugged ACPI_DMAR failures (not
faults) long time ago.

Reviewed by: cem, imp (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D7813

Create PCI_MATCH and pci_match_device

Create a covenience function to match PCI device IDs. It's about 15
years overdue.

Differential Revision: https://reviews.freebsd.org/D15999

Add PCI methods to iterate over the PCI capabilities

VirtIO V1 provides configuration in multiple VENDOR capabilities so this
allows all of the configuration to be discovered.

Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D14325

Do pass removing some write-only variables from the kernel.

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

Add device location wiring to the pci bus.

This allows one to specify, for example, that if there's an igb card
in bus 12, slot 0, function 0, it should be assigned igb5. If there
isn't, or there's one in a different slot, normal numbering rules
apply (hinted units are skipped). Adding 'hint.igb.5.at="pci12:0:0"'
or 'hint.igb.5.at="pci0:12:0:0"' to /boot/device.hints will accomplish
this. The double quotes are important.

The kernel only accepts the strings (in shell notation):
pci$d:$b:$s:$f
and pci$b:$s:$f
where $d is the pci domain, $b is the pci bus number, $s is the slot
number and $f is the function number. A string compare is done with
the current device to avoid another string parser in the kernel. All
numbers are unsigned decimal without leading zeros.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D13546

sys/dev: further adoption of SPDX licensing ID tags.

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.

Inline pcie_link_{status,caps} where needed. Remove them as they
aren't really needed and I don't want to document them.

Suggested by: jhb@
Sponsored by: Netflix

Provide pcie_link_status and pcie_link_cap convenience functions.

Sponsored by: Netflix

Remove embedded newlines from sysctl variable descriptions

PR: 112556
Submitted by: Willem Jan Withagen <wjw@digiware.nl> (earlier version)
Reported by: Willem Jan Withagen, ighighi@gmail.com
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp

pci: fix write order when sizing BARs

According to the PCI Local Specification rev. 3.0 in case of a 64-bit
BAR both the low and the high parts of the register should be set to
~0 before attempting to read back the size.

So far I have found no single device that has problems with the
previous approach, but I think it's better to stay on the safe size.

This commit should not introduce any functional change.

MFC after: 3 weeks
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential revision: https://reviews.freebsd.org/D11750

alc: Add Killer E2500 support

Reviewed by: jhb, yongari
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9058

"Buses" is the preferred plural of "bus"

Replace archaic "busses" with modern form "buses."

Intentionally excluded:
* Old/random drivers I didn't recognize
* Old hardware in general
* Use of "busses" in code as identifiers

No functional change.

http://grammarist.com/spelling/buses-busses/

PR: 216099
Reported by: bltsrc at mail.ru
Sponsored by: Dell EMC Isilon

Add MSIX rewrite table quirk for use with VMs.

This patch solves IRQ generation problems using the mlx5en(4) driver
with xenserver v6.5.0 in SRIOV and PCI-passthrough modes.

Until further the hw.pci.msix_rewrite_table quirk must be set manually
in /boot/loader.conf .

Reviewed by: jhb @
Sponsored by: Mellanox Technologies
MFC after: 2 weeks

Add names for some DASP devices.

Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>
MFC after: 1 week

pci: Clear the MEM/PORT_EN bit when updating PCI BAR

It's unsafe to update the BAR when the related EN bit is set.

Submitted by: Dexuan Cui <decui microsoft com>
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D7914

Fix invalid vendor ID constant (typo).

During a bus rescan the check for an invalid vendor ID of a subfunction
used the wrong constant.

Submitted by: Dexuan Cui <decui@microsoft.com>
MFC after: 3 days

Reset PCI pass through devices via PCI-e FLR during VM start and end.

Add routines to trigger a function level reset (FLR) of a PCI-express
device via the PCI-express device control register. This also includes
support routines to wait for pending transactions to complete as well
as calculating the maximum completion timeout permitted by a device.

Change the ppt(4) driver to reset pass through devices before attaching
to a VM during startup and before detaching from a VM during shutdown.

Reviewed by: imp, wblock (earlier version)
MFC after: 1 month
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7751

Update the I/O MMU in bhyve when PCI devices are added and removed.

When the I/O MMU is active in bhyve, all PCI devices need valid entries
in the DMAR context tables. The I/O MMU code does a single enumeration
of the available PCI devices during initialization to add all existing
devices to a domain representing the host. The ppt(4) driver then moves
pass through devices in and out of domains for virtual machines as needed.
However, when new PCI devices were added at runtime either via SR-IOV or
HotPlug, the I/O MMU tables were not updated.

This change adds a new set of EVENTHANDLERS that are invoked when PCI
devices are added and deleted. The I/O MMU driver in bhyve installs
handlers for these events which it uses to add and remove devices to
the "host" domain.

Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7667

Add Killer E2400 Gigabit Ethernet support.
It seems Killer E2200/E2400 has a BIOS misconfiguration or silicon
bug which triggers DMA write errors when driver uses advertised
maximum payload size. Force the maximum payload size to 128 bytes
in DMA configuration.
This change should fix occasional DMA write errors reported on
Killer E2200.

Tested by: <psy0nic@sys-tek.org>

Add pci_get_max_payload() to fetch the PCI-express maximum payload size.

Approved by: re (gjb)
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D6951

Re-commit r299467 having fixed the build:

Add a new get_id interface to pci and pcib. This will allow us to both
detect failures, and get different PCI IDs.

For the former the interface returns an int to signal an error. The ID is
returned at a uintptr_t * argument.

For the latter there is a type argument that allows selecting the ID type.
This only specifies a single type, however a MSI type will be added
to handle the need to find the ID the hardware passes to the ARM GICv3
interrupt controller.

A follow up commit will be made to remove pci_get_rid.

Reviewed by: jhb, rstone (previous version)
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D6239

Revert r299467 to fix the kernel build.

$ svn merge -c -299467 .

Approved by: build being broken for six hours

Add a new get_id interface to pci and pcib. This will allow us to both
detect failures, and get different PCI IDs.

For the former the interface returns an int to signal an error. The ID is
returned at a uintptr_t * argument.

For the latter there is a type argument that allows selecting the ID type.
This only specifies a single type, however a MSI type will be added
to handle the need to find the ID the hardware passes to the ARM GICv3
interrupt controller.

A follow up commit will be made to remove pci_get_rid.

Reviewed by: jhb, rstone
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D6239

Restore name=value format of PCI location strings.

When devctl was added, the location string for PCI devices was changed to
use the PCI "selector" that pciconf and devctl accept. However, devd
assumes that location strings are formatted as a list of name=value pairs.
As a result, devd is no longer parsing any of the values out of PCI
device events. Restore the previous format of the PCI location strings
to restore the location and slot keywords in case any devd scripts are
using this. Add the "selector" as a new 'dbsf' location variable.

Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D6253

Fix build without "options PCI_IOV".

Save and restore SRIOV-related config registers.

Save the value of the IOV control and page size registers and restore
them (along with the VF count) in pci_cfg_save/pci_cfg_restore. This
ensures ARI remains enabled if a PF driver resets itself during the
PCI_IOV_INIT callback. This might also properly restore SRIOV state
across suspend/resume.

Reviewed by: rstone, vangyzen
Differential Revision: https://reviews.freebsd.org/D6192

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

Fix an off by one error when remapping MSI-X vectors.

pci_remap_msix() can be used to alter the mapping of allocated
MSI-X vectors to the MSI-X table. The code had an off by one error
when adding the IRQ resources after performing a remap. This was
fatal for any vectors in the table that used the "last" valid IRQ as
those vectors were assigned a garbage IRQ value.

MFC after: 3 days

Fix build for systems without PCI_RES_BUS.

Submitted by: vangyzen

Fix PCI bus detach to delete child devices.

Differential Revision: https://reviews.freebsd.org/D6020

Implement a PCI bus rescan method.

Rescanning a PCI bus uses the following steps:
- Fetch the current set of child devices and save it in the 'devlist'
array.
- Allocate a parallel array 'unchanged' initalized with NULL pointers.
- Scan the bus checking each slot (and each function on slots with a
multifunction device).
- If a valid function is found, look for a matching device in the 'devlist'
array. If a device is found, save the pointer in the 'unchanged' array.
If a device is not found, add a new device.
- After the scan has finished, walk the 'devlist' array deleting any
devices that do not have a matching pointer in the 'unchanged' array.
- Finally, fetch an updated set of child devices and explicitly attach any
devices that are not present in the 'unchanged' array.

This builds on the previous changes to move subclass data management into
pci_alloc_devinfo(), pci_child_added(), and bus_child_deleted().

Subclasses of the PCI bus use custom rescan logic explicitly override the
rescan method to disable rescans.

Differential Revision: https://reviews.freebsd.org/D6018

PCI Enhanced Allocation: Annotate an intentional switch fallthrough

This is a trivial follow-up to r296308. Annotate the intentional fallthrough
to make it clear for future readers and linters.

Reported by: Coverity
CID: 1352716
Discussed with: jhb
Sponsored by: EMC / Isilon Storage Division

Add a new PCI bus interface method to alloc the ivars (dinfo) for a device.

The ACPI and OFW PCI bus drivers as well as CardBus override this to
allocate the larger ivars to hold additional info beyond the stock PCI ivars.

This removes the need to pass the size to functions like pci_add_iov_child()
and pci_read_device() simplifying IOV and bus rescanning implementations.

As a result of this and earlier changes, the ACPI PCI bus driver no longer
needs its own device_attach and pci_create_iov_child methods but can use
the methods in the stock PCI bus driver instead.

Differential Revision: https://reviews.freebsd.org/D5891

Convert pci_delete_child() to a bus_child_deleted() method.

Instead of providing a wrapper around device_delete_child() that the PCI
bus and child bus drivers must call explicitly, move the bulk of the logic
from pci_delete_child() into a bus_child_deleted() method
(pci_child_deleted()). This allows PCI devices to be safely deleted via
device_delete_child().
- Add a bus_child_deleted method to the ACPI PCI bus which clears the
device_t associated with the corresponding ACPI handle in addition to
the normal PCI bus cleanup.
- Change cardbus_detach_card to call device_delete_children() and move
CardBus-specific delete logic into a new cardbus_child_deleted() method.
- Use device_delete_child() instead of pci_delete_child() in the SRIOV code.
- Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which
frees the OpenFirmware device info for each PCI device.

Reviewed by: imp
Tested on: amd64 (CardBus and PCI-e hotplug)
Differential Revision: https://reviews.freebsd.org/D5831

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).

Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.

Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)

Tested PAE and devinfo on virtualbox (live CD)

Special thanks to bz for his testing on ARM.

Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544

Replace all resource occurrences of '0UL/~0UL' with '0/~0'.

Summary:
The idea behind this is '~0ul' is well-defined, and casting to uintmax_t, on a
32-bit platform, will leave the upper 32 bits as 0. The maximum range of a
resource is 0xFFF.... (all bits of the full type set). By dropping the 'ul'
suffix, C type promotion rules apply, and the sign extension of ~0 on 32 bit
platforms gets it to a type-independent 'unsigned max'.

Reviewed By: cem
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5255

Support for Enhanced Allocation in PCI

On some platforms, BAR entries are hardcoded and must not be accessed
using standard method. Add functionality to identify this situation
and configure the bus based on Enhanced Allocation structure.

Obtained from: Semihalf
Sponsored by: Cavium
Approved by: cognet (mentor)
Reviewed by: jhb
Differential revision: https://reviews.freebsd.org/D5242

Convert rman to use rman_res_t instead of u_long

Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.

This is step one in migrating rman to use uintmax_t for resources instead of
u_long.

Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.

This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.

Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075

Add accessor methods to fetch the BAR holding the MSI-X table and PBA.

While here, explicitly note the requirement that the BAR(s) must be
allocated prior to calling pci_alloc_msix().

Reviewed by: andrew, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D4688

Add a new helper function for PCI devices to locate the upstream
PCI-express root port of a given PCI device.

Reviewed by: kib, imp
MFC after: 1 week
Sponsored by: Chelsio
Differential Revision: https://reviews.freebsd.org/D4089

Add helper routines for PCI device drivers to read, write, and modify
PCI-Express capability registers (that is, PCI config registers in the
standard PCI config space belonging to the PCI-Express capability
register set).

Note that all of the current PCI-e registers are either 16 or 32-bits,
so only widths of 2 or 4 bytes are supported.

Reviewed by: imp
MFC after: 1 week
Sponsored by: Chelsio
Differential Revision: https://reviews.freebsd.org/D4088

drop a bunch of white space at end of lines and end of files...
-x -wb apparently doesn't hide end of file white space changes..

This is to reduce the amount of diff for my PCIe HP changes..

Remove several write-only variables, all reported by the gcc 4.9
buildkernel run.

Some of them were write-only under some kernel options, e.g. variables
keeping values only used by CTR() macros. It costs nothing to the
code readability and correctness to eliminate the warnings in those
cases too by removing the local cached values used only for
single-access.

Review: https://reviews.freebsd.org/D2665
Reviewed by: rodrigc
Looked at by: bjk
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Update the pci_cfg_save/restore routines to operate on bridge devices
(type 1 and type 2) as well as leaf devices (type 0). In particular,
this allows the existing PCI bus logic to save and restore capability
registers such as MSI and PCI-express work for bridge devices rather than
requiring that code to be duplicated in bridge drivers. It also means
that bridge drivers no longer need to save and restore basic registers
such as the PCI command register or BARs nor manage powerstates for the
bridge device.

While here, pci_setup_secbus() has been changed to initialize the 'sec'
and 'sub' fields in the 'secbus' structure instead of requiring the pcib
and pccbb drivers to do this in the NEW_PCIB + PCI_RES_BUS case.

Differential Revision: https://reviews.freebsd.org/D2240
Reviewed by: imp, jmg
MFC after: 2 weeks

The minimim grant and maximum latency PCI config registers are only valid
for type 0 devices, not type 1 or 2 bridges. Don't read them for bridge
devices during bus scans and return an error when attempting to read them
as ivars for bridge devices.

Don't leak 'used' in a few error cases.

Reported by: Maxime Villard

Allocate PCI I/O memory spaces for VFs

When creating VFs, we must size each SR-IOV BAR on the PF and
allocate a configuous I/O memory window large enough for every VF.
However, the window only needs to be aligned to a boundary equal
to the size of the window for a single VF.

When a VF attempts to allocate an I/O memory resource, we must
intercept the request in the pci driver and pass it off to the
SR-IOV code, which will allocate the correct window from the
pre-allocated memory space for the PF.

Inform the pci driver about the size and address of the BARs on
the VF when the VF is created. This is required by pciconf -b and
bhyve.

Differential Revision: https://reviews.freebsd.org/D78
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Sandvine Inc.

Emulate the Device ID and Vendor ID registers for VFs

The SR-IOV standard requires VFs to read all-ones when the VID
and DID registers are read. The VMM (hypervisor) is required to
emulate them instead. Make pci_read_config() do this emulation.

Change pci_user.c to use pci_read_config() to read config space
registers instead of going directly to the pcib so that the
emulated VID/DID registers work correctly on VFs. This is
required both for pciconf and bhyve PCI passthrough.

Differential Revision: https://reviews.freebsd.org/D77
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Sandvine Inc.

Implement interface to create SR-IOV Virtual Functions

Implement the interace to create SR-IOV Virtual Functions (VFs).
When a driver registers that they support SR-IOV by calling
pci_setup_iov(), the SR-IOV code creates a new node in /dev/iov
for that device. An ioctl can be invoked on that device to
create VFs and have the driver initialize them.

At this point, allocating memory I/O windows (BARs) is not
supported.

Differential Revision: https://reviews.freebsd.org/D76
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Sandvine Inc.

Refactor PCI resource allocation

Refactor PCI resource allocation code to allow a request for a
memory-mapped I/O window that is a multiple of a requested size.
This is needed by the SR-IOV code because the VF BARs are all
allocated contiguously. We can't just allocate a resource that is
a multiple of a single VF BAR because the size of an allocation
implies its alignment requirement.

Differential Revision: https://reviews.freebsd.org/D71
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Sandvine Inc.

Refactor PCI device creation

Refactor creation of PCI devices into helper methods that can be
used by the VF creation code.

Differential Revision: https://reviews.freebsd.org/D67
Reviewed by: jhb
MFC after: 1 month
Sponsored by: Sandvine Inc.

remove NULL check as M_WAITOK will not return NULL

Reviewed by: jhb
Sponsored by: FreeBSD Foundation

Add a new device control utility for new-bus devices called devctl. This
allows the user to request administrative changes to individual devices
such as attach or detaching drivers or disabling and re-enabling devices.
- Add a new /dev/devctl2 character device which uses ioctls for device
requests. The ioctls use a common 'struct devreq' which is somewhat
similar to 'struct ifreq'.
- The ioctls identify the device to operate on via a string. This
string can either by the device's name, or it can be a bus-specific
address. (For unattached devices, a bus address is the only way to
locate a device.) Bus drivers register an eventhandler to claim
unrecognized device names that the driver recognizes as a valid address.
Two buses currently support addresses: ACPI recognizes any device
in the ACPI namespace via its full path starting with "\" and
the PCI bus driver recognizes an address specification of
'pci[<domain>:]<bus>:<slot>:<func>' (identical to the PCI selector
strings supported by pciconf).
- To make it easier to cut and paste, change the PnP location string
in the PCI bus driver to output a full PCI selector string rather
than 'slot=<slot> function=<func>'.
- Add a devctl(3) interface in libdevctl which provides a wrapper around
the ioctls and is the preferred interface for other userland code.
- Add a devctl(8) program which is a simple wrapper around the requests
supported by devctl(3).
- Add a device_is_suspended() function to check DF_SUSPENDED.
- Add a resource_unset_value() function that can be used to remove a
hint from the kernel environment. This is used to clear a
hint.<driver>.<unit>.disabled hint when re-enabling a boot-time
disabled device.

Reviewed by: imp (parts)
Requested by: imp (changing PCI location string)
Relnotes: yes

- Make PCI_QUIRK_MSI_INTX_BUG work by using the ID of the actual PCI device
for the lookup.
- For devices affected by PCI_QUIRK_MSI_INTX_BUG, ensure PCIM_CMD_INTxDIS
is cleared when using MSI/MSI-X.
- Employ PCI_QUIRK_MSI_INTX_BUG for BCM5714(S)/BCM5715(S)/BCM5780(S) rather
than clearing PCIM_CMD_INTxDIS unconditionally for all devices in bge(4).

MFC after: 3 days

Revert r274635 as it's completely wrong.
The parent of a pci dev device is a pciX device which do not
implement the PCIB_POWER_FOR_SLEEP method from pcib_if.m.

Use the correct device as the power_for_sleep() method
always pass request up to parent bridge.

Reviewed by: jhb
MFC after: 1 week
xMFC: r274386,r274397

Use the correct device (child) when asking the bus layer about which power
state said device should go into.

This was a snafu introduced in the ACPI/PCI awareness separation.

When putting a device into a power state, the bus (and thus firmware,
eg ACPI) should be asked before hand to check whether the device
can indeed go into that power state.

There's a set of nodes in ACPI under each device - the _SxD nodes - which
state which ACPI power state to put the device into when the system is
going into power save state 'x'. So when going into S3, the existence
of an _S3D node would override whatever the system was trying to do.

By default the PCI code wants to put devices into D3 before suspending.

I have a laptop here (Asus Zenbook - check the PR) whose EHCI controller
really wants to be in D2 during suspend, not D3. So if we put it into
D3 and then try to enter S3, everything hangs. The device itself
can go into D3 - it just can't be there when the call to ACPI to enter
S3 occurs. The PCI patch fixes this.

jkim@ noticed that the same is needed for the ACPI child device
enumeration.

Thankyou to Matt Dillon (the programmer, not the actor) for buying me
this particular laptop so I could debug the issues with the Atheros
AR9485 that is in it. It's his fault that I ended up with this
laptop and was sufficiently annoyed by the lack of USB suspend
to go down this rabbit hole.

Tested:

* Thinkpad T400
* Thinkpad X230
* Thinkpad T42
* Thinkpad T60
* Asus Zenbook (see PR)
* Asus EEEPC 701
* Asus EEEPC 1001PX

TODO:

* Figure out what we should do about devices we unload drivers for
that want to be in a specific state when entering S3 / S4 -
the "put devices into D3 if they're not bound to a driver" option
may also mess with things.

PR: kern/194884
Reviewed by: jhb, jkim
MFC after: 1 week
Relnotes: yes
Sponsored by: Matt Dillon <dillon@apollo.backplane.com> (hardware)

Follow up to r225617. In order to maximize the re-usability of kernel code
in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv().
This fixes a namespace collision with libc symbols.

Submitted by: kmacy
Tested by: make universe

Add a bus method to fetch the VM domain for the given device/bus.

* Add a bus_if.m method - get_domain() - returning the VM domain or
ENOENT if the device isn't in a VM domain;
* Add bus methods to print out the domain of the device if appropriate;
* Add code in srat.c to save the PXM -> VM domain mapping that's done and
expose a function to translate VM domain -> PXM;
* Add ACPI and ACPI PCI methods to check if the bus has a _PXM attribute
and if so map it to the VM domain;
* (.. yes, this works recursively.)
* Have the pci bus glue print out the device VM domain if present.

Note: this is just the plumbing to start enumerating information -
it doesn't at all modify behaviour.

Differential Revision: D906
Reviewed by: jhb
Sponsored by: Norse Corp

Oops, fix typo made in r272729.

Add new quirk PCI_QUIRK_MSI_INTX_BUG to pci(4).
QAC AR816x/E2200 controller has a silicon bug that MSI interrupt
does not assert if PCIM_CMD_INTxDIS bit of command register is set.

Reviewed by: jhb

Stage one of multipass suspend/resume

Summary:
Add the beginnings of multipass suspend/resume, by introducing
BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, and move the PCI driver to this.

Reviewers: jhb

Reviewed By: jhb

Differential Revision: https://reviews.freebsd.org/D590

pci: add a new pci_child_added newbus method.

This is needed so when running under Xen the calls to pci_child_added
can be intercepted and a custom Xen method can be used to register
those devices with Xen. This should not include any functional
change, since the Xen implementation will be added in a following
patch and the native implementation is a noop.

Sponsored by: Citrix Systems R&D
Reviewed by: jhb

dev/pci/pci.c:
dev/pci/pci_if.m:
dev/pci/pci_private.h:
dev/pci/pcivar.h:
- Add the pci_child_added newbus method.

pci: make MSI(-X) enable and disable methods of the PCI bus

Make the functions pci_disable_msi, pci_enable_msi and pci_enable_msix
methods of the newbus PCI bus. This code should not include any
functional change.

Sponsored by: Citrix Systems R&D
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D354

dev/pci/pci.c:
- Convert the mentioned functions to newbus methods.
- Fix the callers of the converted functions.

sys/dev/pci/pci_private.h:
dev/pci/pci_if.m:
- Declare the new methods.

dev/pci/pcivar.h:
- Add helpers to call the newbus methods.

ofed/include/linux/pci.h:
- Add define to prevent the ofed version of pci_enable_msix from
clashing with the FreeBSD native version.

Pull in r267961 and r267973 again. Fix for issues reported will follow.

Revert r267961, r267973:

These changes prevent sysctl(8) from returning proper output,
such as:

1) no output from sysctl(8)
2) erroneously returning ENOMEM with tools like truss(1)
or uname(1)
truss: can not get etype: Cannot allocate memory

Extend the meaning of the CTLFLAG_TUN flag to automatically check if
there is an environment variable which shall initialize the SYSCTL
during early boot. This works for all SYSCTL types both statically and
dynamically created ones, except for the SYSCTL NODE type and SYSCTLs
which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to
be used in the case a tunable sysctl has a custom initialisation
function allowing the sysctl to still be marked as a tunable. The
kernel SYSCTL API is mostly the same, with a few exceptions for some
special operations like iterating childrens of a static/extern SYSCTL
node. This operation should probably be made into a factored out
common macro, hence some device drivers use this. The reason for
changing the SYSCTL API was the need for a SYSCTL parent OID pointer
and not only the SYSCTL parent OID list pointer in order to quickly
generate the sysctl path. The motivation behind this patch is to avoid
parameter loading cludges inside the OFED driver subsystem. Instead of
adding special code to the OFED driver subsystem to post-load tunables
into dynamically created sysctls, we generalize this in the kernel.

Other changes:
- Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask"
to "hw.pcic.intr_mask".
- Removed redundant TUNABLE statements throughout the kernel.
- Some minor code rewrites in connection to removing not needed
TUNABLE statements.
- Added a missing SYSCTL_DECL().
- Wrapped two very long lines.
- Avoid malloc()/free() inside sysctl string handling, in case it is
called to initialize a sysctl from a tunable, hence malloc()/free() is
not ready when sysctls from the sysctl dataset are registered.
- Bumped FreeBSD version to indicate SYSCTL API change.

MFC after: 2 weeks
Sponsored by: Mellanox Technologies

Add IOMMU PCI subclass, found on Tyan S8236 motherboard.

Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>
MFC after: 2 weeks

Make uninteresting PCI devices with no attached drivers only print out
on a verbose boot

MFC after: 2 weeks

Correct a PCI enumeration bug introduced in r264011

Ensure that first_func is set to 0 on every iteration of the PCI slot
enumeration loop after the first. There is a continue statement that would
cause first_func to stay at 1 any PCI device where slot 0 has no functions
until we find a slot that does have a function. This would cause us to
not enumerate the first PCI function on the device.

Credit to markj@ for spotting the bug.

X-MFC-With: r264011

Add support for PCIe ARI

PCIe Alternate RID Interpretation (ARI) is an optional feature that
allows devices to have up to 256 different functions. It is
implemented by always setting the PCI slot number to 0 and
re-purposing the 5 bits used to encode the slot number to instead
contain the function number. Combined with the original 3 bits
allocated for the function number, this allows for 256 functions.

This is enabled by default, but it's expected to be a no-op on currently
supported hardware. It's a prerequisite for supporting PCI SR-IOV, and
I want the ARI support to go in early to help shake out any bugs in it.
ARI can be disabled by setting the tunable hw.pci.enable_ari=0.

Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.

Add a method to get the PCI RID for a device.

Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.

Revert PCI RID changes.

My PCI RID changes somehow got intermixed with my PCI ARI patch when I
committed it. I may have accidentally applied a patch to a non-clean
working tree. Revert everything while I figure out what went wrong.

Pointy hat to: rstone

Add a method to get the PCI Routing ID for a device

Reviewed by: kib
Sponsored by: Sandvine, Inc

Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge
I/O windows, the default is to preserve the firmware-assigned resources.
PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture
defines a PCI_RES_BUS resource type.
- Add a helper API to create top-level PCI bus resource managers for each
PCI domain/segment. Host-PCI bridge drivers use this API to allocate
bus numbers from their associated domain.
- Change the PCI bus and CardBus drivers to allocate a bus resource for
their bus number from the parent PCI bridge device.
- Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the
full range of bus numbers from secbus to subbus from their parent bridge.
The drivers also always program their primary bus register. The bridge
drivers also support growing their bus range by extending the bus resource
and updating subbus to match the larger range.
- Add support for managing PCI bus resources to the Host-PCI bridge drivers
used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib).
- Define a PCI_RES_BUS resource type for amd64 and i386.

Reviewed by: imp
MFC after: 1 month

Add two tunables to ignore certain firmware-assigned resources. These
are mostly useful for debugging.
- hw.pci.clear_bars ignores all firmware-assigned ranges for BARs when
set.
- hw.pci.clear_pcib ignores all firmware-assigned ranges for PCI-PCI
bridge I/O windows when set.

MFC after: 1 week

Simplify pci_reserve_map() by calling resource_list_reserve() to allocate
the resource after creating a resource list entry rather than reimplementing
it by hand.

MFC after: 1 week

Properly set the alignment flags when allocating the initial range for a
BAR. This only really matters when pci_do_realloc_bars is enabled and
the initial allocation of a specific range fails.

MFC after: 1 week

Add support for displaying VPD for PCI devices via pciconf.
- Store the length of each read-only VPD value since not all values are
guaranteed to be ASCII values (though most are).
- Add a new pciio ioctl to fetch VPD for a single PCI device. The values
are returned as a list of variable length records, one for the device
name and each keyword.
- Add a new -V flag to pciconf's list mode which displays VPD data for
each device.

MFC after: 1 week

Make pci_get_dma_tag() non-static. Since the function is only
referenced by pointer, making it non-static should not have even the
negligible impact on the existing code.

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Move the PCI_DMA_BOUNDARY definition into the pcivar.h.

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

Properly handle I/O windows in bridges with the ISA enable bit set. These
beasts still exist unfortunately. More details can be found in other
references, but the short version is that bridges with this bit set ignore
I/O port ranges that alias to valid ISA I/O port ranges. In the driver
this requires not allocating these alias regions from the parent device
(so they are free to be acquired by ISA devices), and ensuring no child
devices use resources from these alias regions.
- Change the pcib_window structure to allow for an array of backing
resources rather than a single resource and update the existing code
to cope with this. Some of the coping requires using the saved
base and limit values in pcib_window instead of using rman operations
on the backing resource.
- Add special handling for allocating and adjusting the I/O port window
of an ISA-enabled bridge to only allocate the non-alias ranges and
add those to the associated resource manager.
- Reject I/O port allocations for a fixed request that conflicts with an
ISA alias range.
- Remove the "no prefected decode" verbose printf during boot. The absence
of a "prefetched decode" line is sufficient.
- Replace the "subtractively decoded bridge" verbose printf with a single
printf that lists all the "special" decoding modes of a bridge: ISA,
subtractive, and VGA.
- Add a custom bus_release_resource() method to the PCI bus driver so that
it can properly free resources for I/O windows of PCI-PCI bridges.
(These resources are not stored in the bridge device's resource list.)

PR: misc/179033
MFC after: 2 weeks

- As it turns out, not only MSI-X is broken for devices passed through by
VMware up to at least ESXi 5.1. Actually, using INTx in that case instead
may still result in interrupt storms, with MSI being the only working
option in some configurations. So introduce a PCI_QUIRK_DISABLE_MSIX quirk
which only blacklists MSI-X but not also MSI and use it for the VMware
PCI-PCI-bridges. Note that, currently, we still assume that if MSI doesn't
work, MSI-X won't work either - but that's part of the internal logic and
not guaranteed as part of the API contract. While at it, add and employ
a pci_has_quirk() helper.
Reported and tested by: Paul Bucher
- Use NULL instead of 0 for pointers.

Submitted by: jhb (mostly)
Approved by: jhb
MFC after: 3 days

Make detaching drivers from PCI devices more robust. While here, fix a
bug where a PCI device would be powered down if it failed to probe, but
not when its driver was detached (e.g. via kldunload).
- Add a new helper method resource_list_release_active() which forcefully
releases any active resources of a specified type from a resource list.
- Add a bus_child_detached method for the PCI bus driver which forces any
active resources to be released (and whines to the console if it finds
any) and then powers the device down.
- Call pci_child_detached() if we fail to probe a device when a driver
is kldloaded. This isn't perfect but can avoid leaking resources
from a probe() routine in the kldload case.

Reviewed by: imp, brooks
MFC after: 1 month

Disable hw.pci.realloc_bars by default. It wasn't needed for the original
tester of this fix, and realloc_bars breaks some other cases as a small
BAR that is reallocated can end up grabbing space needed by a much larger
BAR in the existing window of a PCI-PCI bridge.

MFC after: 3 days

Revision 233677 broke certain machines. Specifically, if the firmware/BIOS
assigned conflicting ranges to BARs then leaving the BARs alone could
result in one device stealing mmio accesses intended to go to a second
device. Prior to 233677 the PCI bus driver attempted to handle this case
by clearing the BAR to 0 depending on BARs based at 0 not decoding (which
is not guaranteed to be true). Now when a conflicting BAR is detected the
following steps are taken:

1) If hw.pci.realloc_bars (a new tunable) is enabled (default is enabled),
then ignore the current BAR setting from the firmware and attempt to
allocate a fresh resource range for the BAR.

2) If 1) failed (or was disabled), disable decoding for the relevant
BAR type (e.g. disable mem decoding for a memory BAR) and emit a
warning if booting verbose.

Tested by: Alex Keda <admin@lissyara.su>
MFC after: 1 week

- Complete r231621 by also blacklisting the bridge used by VMware for PCIe
devices. While at it, update the comment now that we know that MSI-X
doesn't work with ESXi 5.1 for Intel 82576 either and the underlying issue
is a bug in the MSI-X allocation code of the hypervisor.
Reported by: Harald Schmalzbauer
- Make the nomatch table const.

MFC after: 1 week

Remove the quirk to allow use of MSI when the guest is running inside bhyve.

This became redundant after the hostbridge presented to the guest started
advertising the PCI-E capability (r246846).

Obtained from: NetApp

Add quirk to indicate that the bhyve hostbridge is capable of supporting
MSI and MSI-X even though it does not advertise the PCI-E capability
itself.

Obtained from: NetApp

Remove duplicate const specifiers in many drivers (I hope I got all of
them, please let me know if not). Most of these are of the form:

static const struct bzzt_type {
[...list of members...]
} const bzzt_devs[] = {
[...list of initializers...]
};

The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).

I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).

Reviewed by: yongari, marius
MFC after: 1 week

Teach FreeBSD to detect that it is a guest running inside BHyVe.

Reviewed by: grehan
Obtained from: NetApp

The correct generic term for PCIS_STORAGE_NVM is "NVM" not "NVM Express".

Submitted by: jimharris
MFC after: 6 days

Recognise NVM Express devices and pretty-print their name.

MFC after: 1 week

Align the PCI Express #defines with the style used for the PCI-X
#defines. This also has the advantage that it makes the names more
compact, iand also allows us to correct the non-uniform naming of
the PCIM_LINK_* defines, making them all consistent amongst themselves.

This is a mostly mechanical rename:
s/PCIR_EXPRESS_/PCIER_/g
s/PCIM_EXP_/PCIEM_/g
s/PCIM_LINK_/PCIEM_LINK_/g

When this is MFC'd, #defines will be added for the old names to assist
out-of-tree drivers.

Discussed with: jhb
MFC after: 1 week

Only check to see if a memory resource is a PCI ROM BAR when activating
and deactivating PCI resources. Previously, if a device had more than
48 MSI interrupts, then activating message 48 (which has a rid == PCIR_BIOS)
would incorrectly try to enable the PCI ROM BAR.

Tested by: Olivier Cinquin ocinquin uci edu
MFC after: 3 days

Fix couple of style nits.

Revert r233662 and generalize the hack. Writing zero to BAR actually does
not disable it and it is even harmful as hselasky found out. Historically,
this code was originated from (OLDCARD) CardBus driver and later leaked into
PCI driver when CardBus was newbus'ified and refactored with PCI driver.
However, it is not really necessary even for CardBus.

Reviewed by: hselasky, imp, jhb

Use a more proper fix for enabling HT MSI mapping windows on Host-PCI
bridges. Rather than blindly enabling the windows on all of them, only
enable the window when an MSI interrupt is enabled for a device behind
the bridge, similar to what already happens for HT PCI-PCI bridges.

To implement this, each x86 Host-PCI bridge driver has to be able to
locate it's actual backing device on bus 0. For ACPI, use the _ADR
method to find the slot and function of the device. For the non-ACPI
case, the legacy(4) driver already scans bus 0 looking for Host-PCI
bridge devices. Now it saves the slot and function of each bridge that
it finds as ivars that the Host-PCI bridge driver can then use in its
pcib_map_msi() method.

This fixes machines where non-MSI interrupts were broken by the previous
round of HT MSI changes.

Tested by: bapt
MFC after: 1 week

Fix for boot issue: Don't disable BARs on AGP devices. In general:
Don't disable BARs on any PCI display devices, because doing that can
sometimes cause the main memory bus to stop working, causing all
memory reads to return nothing but 0xFFFFFFFF, even though the memory
location was previously written. After a while a privileged
instruction fault will appear and then nothing more can be debugged.
The reason for this behaviour is unknown.

MFC after: 1 week

Add a PCI quirk to ignore PCI map registers from configuration space.
For example, some BIOS for AMD SB600 south bridge may map HPET MMIO base
address as a memory BAR for SMBus controller depending on a PM register
configuration. Before r231161 (and r232086, subsequent MFC to stable/9),
it was not fatal but hpet(4) just failed to attach. Since we probe and
attach HPET earlier than PCI devices now, it caused unfortunate hard lockup.
With this patch, it does not hang any more and HPET works at the same time.
Clean up some style nits while I am in the neighborhood.

PR: kern/165647
Reviewed by: jhb
MFC after: 3 days

Save more of config space for PCI Express and PCI-X devices.

Expand pci_save_state and pci_restore_state to save more of
the config state for PCI Express and PCI-X devices. Various
writable control registers are present in PCI Express that
can potentially be lost over suspend/resume cycle.

This change is modeled after similar functionality in Linux.

Reviewed by: wlosh,jhb
MFC after: 1 month

Remove the PAE-specific 2GB DMA boundary since HEAD now supports a proper 4G
boundary for PAE.

Simplify the PCI bus dma tag code a bit. First, don't create a tag at
all for platforms that only have 32-bit bus addresses. Second, remove
the 'tag_valid' flag from the softc. Instead, if we don't create a
tag in pci_attach_common(), just cache the value of our parent's tag
so that we always have a valid tag to return.

Expand the set of APIs available for locating PCI capabilities:
- pci_find_extcap() is repurposed to be used for fetching PCI-express
extended capabilities (PCIZ_* constants in <dev/pci/pcireg.h>).
- pci_find_htcap() can be used to locate a specific HyperTransport
capability (PCIM_HTCAP_* constants in <dev/pci/pcireg.h>).
- Cache the starting location of the PCI-express capability for PCI-express
devices in PCI device ivars.

Fix a typo.

- Add a bus_dma tag to each PCI bus that is a child of a Host-PCI bridge.
The tag enforces a single restriction that all DMA transactions must not
cross a 4GB boundary. Note that while this restriction technically only
applies to PCI-express, this change applies it to all PCI devices as it
is simpler to implement that way and errs on the side of caution.
- Add a softc structure for PCI bus devices to hold the bus_dma tag and
a new pci_attach_common() routine that performs actions common to the
attach phase of all PCI bus drivers. Right now this only consists of
a bootverbose printf and the allocate of a bus_dma tag if necessary.
- Adjust all PCI bus drivers to allocate a PCI bus softc and to call
pci_attach_common() from their attach routines.

MFC after: 2 weeks

Add pci_save_state() and pci_restore_state() wrappers around
pci_cfg_save() and pci_cfg_restore() for device drivers to use when
saving and restoring state (e.g. to handle device-specific resets).

Reviewed by: imp
MFC after: 2 weeks

Use pci_printf() instead of a home-rolled version in the VPD parsing code.

- As it turns out, MSI-X is broken for at least LSI SAS1068E when passed
through by VMware so blacklist their PCI-PCI bridge for MSI/MSI-X here.
Note that besides currently there not being a quirk type that disables
MSI-X only and there's no evidence that MSI doesn't work with the VMware
pass-through, it's really questionable whether MSI generally works in
that setup as VMware only mention three know working devices [1, p. 4].
Also not that this quirk entry currently doesn't affect the devices
emulated by VMware in any way as these don't claim support MSI/MSI-X to
begin with. [2]
While at it, make the PCI quirk table const and static.
- Remove some duplicated empty lines.
- Use DEVMETHOD_END.

PR: 163812, http://forums.freebsd.org/showthread.php?t=27899 [2]
Reviewed by: jhb
MFC after: 3 days

Properly return success once a matching VPD entry is found in
pci_get_vpd_readonly_method(). Previously the loop was always running
to completion and falling through to failing with ENXIO.

PR: kern/164313
Submitted by: Chuck Tuffli chuck tuffli net
MFC after: 1 week

Add missing XHCI early takeover code. The XHCI takeover code
is supposed to disable the BIOS from using the XHCI controller
after bootup.

Approved by: re (kib)
Reported by: Mike Tancsa
MFC after: 1 week

PCIB_ALLOC_MSIX() may already fail on the first pass, f.e. when the PCI-PCI
bridge is blacklisted. In that case just return from pci_alloc_msix_method(),
otherwise we continue without a single MSI-X resource, causing subsequent
attempts to use the seemingly available resource to fail or when booting
verbose a NULL-pointer dereference of rle->start when trying to print the
IRQ in pci_alloc_msix_method().

Reviewed by: jhb
MFC after: 1 week

Implement pci_find_class(9), the function to find a pci device by its class.

Sponsored by: The FreeBSD Foundation
Reviewed by: jhb
MFC after: 1 week

Minor whitespace and style fixes.

More properly handle Cardbus cards that that store their CIS in a BAR after
the recent changes to track BAR state explicitly. The code would now
attempt to add the same BAR twice in this case. Instead, change this so
that it recognizes this case and only adds it once and do not delete the
BAR outright after parsing the CIS.

Tested by: bschmidt

Reimplement how PCI-PCI bridges manage their I/O windows. Previously the
driver would verify that requests for child devices were confined to any
existing I/O windows, but the driver relied on the firmware to initialize
the windows and would never grow the windows for new requests. Now the
driver actively manages the I/O windows.

This is implemented by allocating a bus resource for each I/O window from
the parent PCI bus and suballocating that resource to child devices. The
suballocations are managed by creating an rman for each I/O window. The
suballocated resources are mapped by passing the bus_activate_resource()
call up to the parent PCI bus. Windows are grown when needed by using
bus_adjust_resource() to adjust the resource allocated from the parent PCI
bus. If the adjust request succeeds, the window is adjusted and the
suballocation request for the child device is retried.

When growing a window, the rman_first_free_region() and
rman_last_free_region() routines are used to determine if the front or
end of the existing I/O window is free. From using that, the smallest
ranges that need to be added to either the front or back of the window
are computed. The driver will first try to grow the window in whichever
direction requires the smallest growth first followed by the other
direction if that fails.

Subtractive bridges will first attempt to satisfy requests for child
resources from I/O windows (including attempts to grow the windows). If
that fails, the request is passed up to the parent PCI bus directly
however.

The PCI-PCI bridge driver will try to use firmware-assigned ranges for
child BARs first and only allocate a "fresh" range if that specific range
cannot be accommodated in the I/O window. This allows systems where the
firmware assigns resources during boot but later wipes the I/O windows
(some ACPI BIOSen are known to do this) to "rediscover" the original I/O
window ranges.

The ACPI Host-PCI bridge driver has been adjusted to correctly honor
hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge
makes a wildcard request for an I/O window range.

The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option
is enabled. This is a transition aide to allow platforms that do not
yet support bus_activate_resource() and bus_adjust_resource() in their
Host-PCI bridge drivers (and possibly other drivers as needed) to use the
old driver for now. Once all platforms support the new driver, the
kernel option and old driver will be removed.

PR: kern/143874 kern/149306
Tested by: mav

Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver,
generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge
drivers.

Only align MSI message groups based on the number of messages being
allocated, not the maximum number of messages the device supports. The
spec only requires the former, and I believe I implemented the latter due
to misunderstanding an e-mail. In particular, this fixes an issue where
having several devices that all support 16 messages can run out of
IDT vectors on x86 even though the driver only uses a single message.

Submitted by: Bret Ketchum bcketchum of gmail
MFC after: 1 week

Explicitly track the state of all known BARs for each PCI device. The PCI
bus driver will now remember the size of a BAR obtained during the initial
bus scan and use that size when doing lazy resource allocation rather than
resizing the BAR. The bus driver will now also report unallocated BARs to
userland for display by 'pciconf -lb'. Psuedo-resources that are not BARs
(such as the implicit I/O port resources for master/slave ATA controllers)
will no longer be listed as BARs in 'pciconf -lb'. During resume, BARs are
restored from their new saved state instead of having the raw registers
saved and restored across resume. This also fixes restoring BARs at
unusual loactions if said BAR has been allocated by a driver.

Add a constant for the offset of the ROM BIOS BAR in PCI-PCI bridges and
properly handle ROM BIOS BARs in PCI-PCI bridges. The PCI bus now also
properly handles the lack of a ROM BIOS BAR in a PCI-Cardbus bridge.

Tested by: jkim

Rename pci_find_extcap() to pci_find_cap(). PCI now uses the term
"extended capabilities" to refer to the new set of capability structures
starting at offset 0x100 in config space for PCI-express devices. For now
both function names will still work. I will merge this to older branches
to ease driver portability, but 9.0 will ship with a new pci_find_extcap()
function that locates extended capabilities instead.

Reviewed by: imp
MFC after: 1 week

Partially revert previous change. Drop the quirk to disable MSI for HT
chipsets that do not have an HT slave at 0:0:0:0. The Linux quirk is
actually specific to Nvidia chipsets and the check I had added was in
the wrong place.

Prodded by: nathanw

Fix a few issues with HyperTransport devices and MSI interrupts:
- Always enable the HyperTransport MSI mapping window for HyperTransport
to PCI bridges (these show up as HyperTransport slave devices).
The mapping windows in PCI-PCI bridges are enabled by existing code
in the PCI-PCI bridge driver as MSI requests propagate up the device
tree, but Host-PCI bridges don't really show up in that tree.
- If the PCI device at domain 0 bus 0 slot 0 function 0 is not a
HyperTransport device, then blacklist MSI on any other HT devices in
the system. Linux has a similar quirk.

PR: kern/155442
Tested by: Zack Dannar zdannar of gmail
MFC after: 1 week

Properly handle BARs bigger than 4G. The '1' was treated as an int
causing the size calculation to be truncated to the size of an int
(32-bits on all current architectures).

Submitted by: Anish akgupt3 of gmail
MFC after: 1 week

Use the preload_fetch_addr() and preload_fetch_size() convenience
functions to obtain the address and size of the PCI vendor data.

Sponsored by: Juniper Networks.

Resume critical PCI devices (and their children) first, then everything else
later. This give us better chance to catch device driver problems.

The EHCI_CAPLENGTH and EHCI_HCIVERSION registers are actually sub-registers
within the first 4 bytes of the EHCI memory space. For controllers that
use big-endian MMIO, reading them with 1- and 2-byte reads would then
return the wrong values. Instead, read the combined register with a 4-byte
read and mask out the interesting quantities.

- Add a new PCI quirk to whitelist an old chipset that doesn't support
PCI-express or PCI-X capabilities if we are running in a virtual machine.
- Whitelist the Intel 82440 chipset used by QEMU.

Tested by: jfv
MFC after: 1 week

Clarify a misleading comment. The test in pci_reserve_map() was meant to
ignore BARs that are invalid due to having a size of zero, not to ignore
BARs with an existing base of zero. While here, reorganize the code
slightly to make the intent clearer.

Reported by: avg
MFC after: 1 week

Update PCI power management registers per PCI Bus Power Management Interface
Specification Rev. 1.2. Rename pp_pcmcsr field of PM capabilities to pp_bse
to avoid further confusions and adjust some comments accordingly. The real
PMCSR (Power Management Control/Status Register) is PCIR_POWER_STATUS and
it is actually BSE (PCI-to-PCI Bridge Support Extensions) register.

Introduce a new tunable 'hw.pci.do_power_suspend'. This tunable lets you
avoid PCI power state transition from D0 to D3 for suspending case. Default
is 1 or enabled.

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.

Remove PCI header type 0 restriction from power state changes. PCI config.
registers for bridges are saved and restored since r200341.

OK'ed by: imp, jhb

Do not apply do_power_resume for suspending case. When do_powerstate was
splitted into do_power_resume and do_power_nodriver, it became stale.

Remove unnecessary castings and fix couple of style(9) nits.

Move setting power state for children into a separate function as they were
essentially the same. This also restores hw.pci.do_power_resume tunable,
which was broken since r211430.

Reviewed by: jhb

Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This
method is used by the PCI bus driver to query the power management system
to determine the proper device state to be used for a device during suspend
and resume. For the ACPI PCI bridge drivers this calls
acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from
the PCI and PCI-PCI bridge drivers.

Reviewed by: jkim

Consistently check header type after reading PCIR_HDRTYPE register.
While I'm here use defined macro instead of using magic numbers for
header type.

Reviewed by: jhb

Virtualize pci_remap_msi_irq() call from general MSI code. It allows MSI
(FSB interrupts) to be used by non-PCI devices, such as HPET.

MFC r208149,208285:

Add support for the U4 PCI-Express bridge chipset used in late-generation
Powermac G5 systems. MSI and several other things are not presently
supported.

The U3/U4 internal device support portions of this change were contributed
by Andreas Tobler.

Honor hw.pci.do_power_nodriver on resume. Power-down devices without
driver attached.

Add support for the U4 PCI-Express bridge chipset used in late-generation
Powermac G5 systems. MSI and several other things are not presently
supported.

The U3/U4 internal device support portions of this change were contributed
by Andreas Tobler.

MFC after: 1 week

MFC rev 198431:
Have the early USB takeover only enabled for i386 and amd64
by default. This also avoids a panic on PowerPC.

MFC r203528:
Add pci_get|set_max_read_req() helper functions to control maximum PCIe
read request size.

Add pci_get|set_max_read_req() helper functions to control maximum PCIe
read request size.

Reviewed by: jhb@

Move the PCI-specific logic of removing a cardbus device into a
pci_delete_child() function called by the cardbus driver. The new function
uses resource_list_unreserve() to release the BARs decoded by the device
being removed.

Reviewed by: imp
Tested by: brooks

Teach the PCI bus driver to handle PCIR_BIOS BARs properly and remove special
handling for the PCIR_BIOS decoding enable bit from the cardbus driver.
The PCIR_BIOS BAR does include type bits like other BARs. Instead, it is
always a 32-bit non-prefetchable memory BAR where the low bit is used as a
flag to enable decoding.

Reviewed by: imp

Remove no longer used pci_release_resource().

Implement a rudimentary suspend/resume methods for PCI P2P bridge.

Reviewed by: jhb, imp

MFC r199814

Disable interrupts after doing early takeover of the usb controller in case usb
isnt actually compiled in (or kldloaded) as the controller could cause spurious
interrupts.

For some buses, devices may have active resources assigned even though they
are not allocated by the device driver. These resources should still appear
allocated from the system's perspective so that their assigned ranges are
not reused by other resource requests. The PCI bus driver has used a hack
to effect this for a while now where it uses rman_set_device() to assign
devices to the PCI bus when they are first encountered and later assigns
them to the actual device when a driver allocates a BAR. A few downsides of
this approach is that it results in somewhat confusing devinfo -r output as
well as not being very easily portable to other bus drivers.

This commit adds generic support for "reserved" resources to the resource
list API used by many bus drivers to manage the resources of child devices.
A resource may be reserved via resource_list_reserve(). This will allocate
the resource from the bus' parent without activating it.
resource_list_alloc() recognizes an attempt to allocate a reserved resource.
When this happens it activates the resource (if requested) and then returns
the reserved resource. Similarly, when a reserved resource is released via
resource_list_release(), it is deactivated (if it is active) and the
resource is then marked reserved again, but is left allocated from the
bus' parent. To completely remove a reserved resource, a bus driver may
use resource_list_unreserve(). A bus driver may use resource_list_busy()
to determine if a reserved resource is allocated by a child device or if
it can be unreserved.

The PCI bus driver has been changed to use this framework instead of
abusing rman_set_device() to keep track of reserved vs allocated resources.

Submitted by: imp (an older version many moons ago)
MFC after: 1 month

Disable interrupts after doing early takeover of the usb controller in case usb
isnt actually compiled in (or kldloaded) as the controller could cause spurious
interrupts.

Tested by: Florian Smeets

MFC r198151

Workaround buggy BIOS code in USB regard. By doing the BIOS to OS handover for
all host controllers at the same time, we avoid problems where the BIOS will
actually write to the USB registers of all the USB host controllers every time
we handover one of them, and consequently reset the OS programmed values.

BIOSes, buggy or otherwise, are i386 or amd64 specific.
Have the early USB takeover enabled for i386 and amd64
by default.
This also avoids a panic on PowerPC where the resource
isn't released properly and we find a busy resource
when the USB host controller wants to allocate it...

Workaround buggy BIOS code in USB regard. By doing the BIOS to OS handover for
all host controllers at the same time, we avoid problems where the BIOS will
actually write to the USB registers of all the USB host controllers every time
we handover one of them, and consequently reset the OS programmed values.

Submitted by: avg
Reviewed by: jhb

MFC 197406:
Don't reread the command register to see if enabling I/O or memory
decoding "took". Other OS's that I checked do not do this and it breaks
some amdpm(4) devices. Prior to 7.2 we did not honor the error returned
when this failed anyway, so this in effect restores previous behavior.

Approved by: re (kib)

Don't reread the command register to see if enabling I/O or memory
decoding "took". Other OS's that I checked do not do this and it breaks
some amdpm(4) devices. Prior to 7.2 we did not honor the error returned
when this failed anyway, so this in effect restores previous behavior.

PR: kern/137668
Tested by: Aurelien Mere aurelien.mere amc-os.com
MFC after: 3 days

Add a MD __PCI_BAR_ZERO_VALID which denotes that BARs containing 0
actually specify valid bases that should be treated just as normal.
The PCI specifications have no indication that 0 would be a magic value
indicating a disabled BAR as commonly used on at least amd64 and i386
but not sparc64. It's unclear what to do in pci_delete_resource()
instead of writing 0 to a BAR though as there's no (other) way do
disable individual BARs so its decoding is left enabled in case of
__PCI_BAR_ZERO_VALID for now.

Approved by: re (kib), jhb
MFC after: 1 week

Enable MSI in the MSI capability registers any time that the first message
in an MSI group is enabled, not just if the address/data pair are not
initialized.

Reported by: rnoland
MFC after: 1 week

Import ACPICA 20090521.

Chase ACPICA API changes (for kernel and boot loader).

Include <machine/stdarg.h> for va_*(). I'm not sure how this compiled
on amd64 without this.

Add an internal pci_printf() routine similar to device_printf() except
that it prefixes the output with 'pci<domain>:<bus>:<device>:<function>: '.

Revert junk from last commit. These are WIP and not ready (and don't
match the description of the last commit).

We no longer need to use d_thread_t, migrate to struct thread *.

- Consolidate duplicated code for reading and sizing BARs and writing base
addresses to BARs into new pci_read_bar() and pci_write_bar() routines.
pci_add_map(), pci_alloc_map(), and pci_delete_resource() now use these
routines to work with BARs.
- Just pass the device_t for the new PCI device to various routines instead
of passing the device, bus, slot, and function.

Reviewed by: imp

- Fix spacing in the comment.

Reported by: jhb

- Correct the comment.

MFC after: 3 days

Fix a buglet in revision 189401: when restoring a 64-bit BAR,
write the upper 32-bits in the adjacent bar. The consequences
of the buglet were severe enough though: a machine check.

Invert the logic error for the MSI/MSIX vs INTx case.

Pointyhat to: me

MFC after: 3 days

Always read/write the full 64-bit value of 64-bit BARs. Specifically,
when determining the size of a BAR by writing all 1's to the BAR and
reading back the result, always operate on the full 64-bit size.

Reviewed by: imp
MFC after: 1 month

Honor the prefetchable flag in memory BARs by setting the RF_PREFETCHABLE
flag when calling bus_alloc_resource() to allocate resources from a parent
PCI bridge. For PCI-PCI bridges this asks the bridge to satisfy the
request using the prefetchable memory range rather than the normal
memory range.

Reviewed by: imp
Reported by: scottl
MFC after: 1 week

Extend the management of PCIM_CMD_INTxDIS.

We now explicitly enable INTx during bus_setup_intr() if it is needed.
Several of the ata drivers were managing this bit internally. This is
better handled in pci and it should work for all drivers now.

We also mask INTx during bus_teardown_intr() by setting this bit.

Reviewed by: jhb
MFC after: 3 days

Further refine the handling of resources for BARs in the PCI bus driver.

A while back, Warner changed the PCI bus code to reserve resources when
enumerating devices and simply give devices the previously allocated
resources when they call bus_alloc_resource(). This ensures that address
ranges being decoded by a BAR are always allocated in the nexus0 device
(or whatever device the PCI bus gets its address space from) even if a
device driver is not attached to the device. This patch extends this
behavior further:
- To let the PCI bus distinguish between a resource being allocated by
a device driver vs. merely being allocated by the bus, use
rman_set_device() to assign the device to the bus when it is owned
by the bus and to the child device when it is allocated by the child
device's driver. We can now prevent a device driver from allocating
the same device twice. Doing so could result in odd things like
allocating duplicate virtual memory to map the resource on some
archs and leaking the original mapping.
- When a PCI device driver releases a resource, don't pass the request
all the way up the tree and release it in the nexus (or similar device)
since the BAR is still active and decoding. Otherwise, another device
could later allocate the same range even though it is still in use.
Instead, deactivate the resource and assign it back to the PCI bus
using rman_set_device().
- pci_delete_resource() will actually completely free a BAR including
attemping to disable it.
- Disable BAR decoding via the command register when sizing a BAR in
pci_alloc_map() which is used to allocate resources for a BAR when
the BIOS/firmware did not assign a usable resource range during boot.
This mirrors an earlier fix to pci_add_map() which is used when to
size BARs during boot.
- Move the activation of I/O decoding in the PCI command register into
pci_activate_resource() instead of doing it in pci_alloc_resource().
Previously we could actually enable decoding before a BAR was
initialized via pci_alloc_map().

Glanced at by: bsdimp

Disable INTx when enabling MSI/MSIX

This addresses interrupt storms that were noticed after enabling MSI
in drm. I think this is due to a loose interpretation of the PCI 2.3
spec, which states that a function using MSI is prohibitted from using
INTx. It appears that some vendors interpretted that to mean that they
should handle it in hardware, while others felt it was the drivers
responsibility.

This fix will also likely resolve interrupt storm related issues with
devices other than drm.

Reviewed by: jhb@
MFC after: 3 days

Don't throw away upper 32-bits of the HT MSI address window. In practice
this is harmless since the address window for MSI on x86 is in the lower
4 GB.

Submitted by: mav
MFC after: 1 week

Change the probe priority for PCI and I2C generic bus modules from
numerical constants to BUS_PROBE_GENERIC.

Suggested by: jhb

Disable decoding of BARs by devices before we trash the value in the BAR
by writing all 1's to it to determine its length. This fixes issues with
MCFG on at least some machines where a trashed BAR claimed subsequent
attempts at PCI config transactions because the addresses in the MCFG
window fell in the decoding range of the BAR.

In general it is a bad idea to leave the BARs enabled while we are
frobbing with them in this manner.

Sleuthing by: tegge
MFC after: 1 week

Add ADMA, SATA and SAS mass storage subclasses reporting.

Add HDA multimedia subclass.

Add "SD host controller" subclass name.

- Import the HEAD csup code which is the basis for the cvsmode work.

Cope with errors from device_get_children(). These errors can happen
only in low memory situations, so the error fork of these fixes is
lightly tested, but they should do the least-wrong thing...

Submitted by: Hans Petter Selasky

Cosmetic nit.

Change -1 to 0xfffffffful since the interface returns uint32_t.

Remove the second check for a 64-bit BAR value on a 32-bit system in
pci_add_map(). First, this condition is already handled earlier in
the function. Second, as written the check would never fire as the
'start' value was overwritten with a long value (rman_get_start() returns
long) before the comparison was done.

Discussed with: imp
MFC after: 2 weeks

If the kernel fails to allocate resources for the initial value of a BAR
for a PCI device during the boot-time probe of the parent PCI bus, then
zero the BAR and clear the resource list entry for that BAR. This forces
the PCI bus driver to request a valid resource range from the parent bridge
driver when the device driver tries to allocate the BAR. Similarly, if the
initial value of a BAR is a valid range but it is > 4GB and the current OS
only has 32-bit longs, then do a full teardown of the initial value of the
BAR to force a reallocation.

Reviewed by: imp
MFC after: 1 week

SATA device on some nForce based boards could get confused if MSI is not
used but MSI to HyperTransport IRQ mapping is enabled, and would act as
if MSI is turned on, resulting in interrupt loss.

This commit will,
1. enable MSI mapping on a device only when MSI is enabled for that
device and the MSI address matches the HT mapping window.
2. enable MSI mapping on a bridge only when a downstream device is
allocated an MSI address in the mapping window

PR: kern/118842
Reviewed by: jhb
MFC after: 1 week

Relax the check for a PCI-express chipset by assuming the system is a
PCI-express chipset (and thus has functional MSI) if there are any
PCI-express devices in the system, not requiring a root port device.

With PCI-X the chipset detection has to be very conservative because there
are known systems with PCI-X devices that do not appear to have PCI-X
chipsets. However, with PCI-express I'm not sure it is possible to have
a PCI-express device in a system with a non-PCI-express chipset. If we
assume that is the case then this change is valid. It is also required
for at least some PCI-express systems that don't have any devices with
a root port capability (some ICH9 systems).

MFC after: 1 week
Reported by: jfv

Make VPD register access more robust:

- Implement timing out of VPD register access.[1]
- Fix an off-by-one error of freeing malloc'd space when checksum is invalid.
- Fix style(9) bugs, i.e., sizeof cannot be followed by space.
- Retire now obsolete 'hw.pci.enable_vpd' tunable.

Submitted by: cokane (initial revision)[1]
Reviewed by: marius (intermediate revision)
Silence from: jhb, jmg, rwatson
Tested by: cokane, jkim
MFC after: 3 days

Make the PCI code aware of PCI domains (aka PCI segments) so we can
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
devices as seen by the OS and represented by PCI location strings.
This includes introducing a function pci_find_dbsf(9) which works
like pci_find_bsf(9) but additionally takes a domain number argument
and limiting pci_find_bsf(9) to only search devices in domain 0 (the
only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are
changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order
to no longer report false positives when searching for siblings and
dupe devices in the same domain respectively.
Along with this change the sole host-PCI bridge driver converted to
actually make use of PCI domain support is uninorth(4), the others
continue to use domain 0 only for now and need to be converted as
appropriate later on.
Note that this means that the format of the location strings as used
by pciconf(8) has been changed and that consumers of <sys/pciio.h>
potentially need to be recompiled.

Suggested by: jhb
Reviewed by: grehan, jhb, marcel
Approved by: re (kensmith), jhb (PCI maintainer hat)

In pci_alloc_map(), restore the original value of the BAR for
the duration of the function. The device we would otherwise
have left in an useless state may just as well be the low-level
console. When booting verbose, we do need it addressable if we
want to avoid a MCA.

Approved by: re (kensmith)

Don't completely skip pci_cfg_save() in the PCI nomatch routine if
the power_nodriver tunable is off. pci_cfg_save() already checks the
tunable internally, and no other callers of pci_cfg_save() check the
tunable.

Reviewed by: imp

Fix a typo in a bootverbose printf.

MFC after: 3 days
Submitted by: yongari

Revamp the MSI/MSI-X code a bit to achieve two main goals:
- Simplify the amount of work that has be done for each architecture by
pushing more of the truly MI code down into the PCI bus driver.
- Don't bind MSI-X indicies to IRQs so that we can allow a driver to map
multiple MSI-X messages into a single IRQ when handling a message
shortage.

The changes include:
- Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus
to calculate the address and data values for a given MSI/MSI-X IRQ.
The x86 nexus drivers map this into a call to a new 'msi_map()' function
in msi.c that does the mapping.
- Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index'
parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge
of the MSI-X index for a given MSI-X IRQ.
- The PCI bus driver now stores more MSI-X state in a child's ivars.
Specifically, it now stores an array of IRQs (called "message vectors" in
the code) that have associated address and data values, and a small
virtual version of the MSI-X table that specifies the message vector
that a given MSI-X table entry uses. Sparse mappings are permitted in
the virtual table.
- The PCI bus driver now configures the MSI and MSI-X address/data
registers directly via custom bus_setup_intr() and bus_teardown_intr()
methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the
address and data values for a given message as needed. The MD code
no longer has to call back down into the PCI bus code to set these
values from the nexus' bus_setup_intr() handler.
- The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD
code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get
new values of the address and data fields for a given IRQ. The x86
MSI code uses this when an MSI IRQ is moved to a different CPU, requiring
a new value of the 'address' field.
- The x86 MSI psuedo-driver loses a lot of code, and in fact the separate
MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver
since the only remaining diff between the two is a substring in a
bootverbose printf.
- The PCI bus driver will now restore MSI-X state (including programming
entries in the MSI-X table) on device resume.
- The interface for pci_remap_msix() has changed. Instead of accepting
indices for the allocated vectors, it accepts a mini-virtual table
(with a new length parameter). This table is an array of u_ints, where
each value specifies which allocated message vector to use for the
corresponding MSI-X message. A vector of 0 forces a message to not
have an associated IRQ. The device may choose to only use some of the
IRQs assigned, in which case the unused IRQs must be at the "end" and
will be released back to the system. This allows a driver to use the
same remap table for different shortage values. For example, if a driver
wants 4 messages, it can use the same remap table (which only uses the
first two messages) for the cases when it only gets 2 or 3 messages and
in the latter case the PCI bus will release the 3rd IRQ back to the
system.

MFC after: 1 month

Use more specific local variable pointers to narrow some expressions.

MFC after: 1 week

- HT 2.00b added a new flag to the MSI mapping HT capability to indicate
that the MSI mapping window is fixed at 0xfee00000 and the capability
does not include two more dwords used to program the address. Supporting
this mostly results in quieting spurious warnings during boot about
non-default MSI mapping windows.
- HT 2.00b also added a new HT capability type, so support that in pciconf.

MFC after: 3 days
Tested by: jmg

Add constants for the fields in a BAR. Also, add two new macros
PCI_BAR_(IO|MEM)() that return true if the passed in value from a BAR
is for an IO or memory BAR, respectively.

Reviewed by: imp

- Add missing constants for subclasses.
- Add a few progif constants as well.

Change the VPD code to read the VPD data on-demand when a driver asks for
it via pci_get_vpd_*() rather than always reading it for each device during
boot. I've left the tunable so that it can still be turned off if a device
driver causes a lockup via a query to a broken device, but devices whose
drivers do not use VPD (the vast majority) should no longer result in
lockups during boot, and most folks should not need to tweak the tunable
now.

Tested on: bge(4)
Silence from: jmg

- Use constants for VPD capability register offsets.
- Add missing ()'s around return values.

Add support for chipsets that has NULL'd BAR's for legacy ports.
This allows DMA to be used on a fine little geode system I got here and
most like on lots of older systems like that.

HW donated by: Paul Ghering

Adjust the global MSI blacklisting strategy so we don't have to explicitly
blacklist a bunch of old chipsets. If a system contains a PCI-PCI bridge
that supports PCI-X, assume the chipset supports PCI-X. If a system
contains a PCI-express root port, assume the chipset supports PCI-express.
If the chipset doesn't support either PCI-X or PCI-express, then blacklist
it by default. We should now only need to explicitly blacklist PCI-X or
PCI-express chipsets that don't properly handle MSI.

- Fix an off by one error in pci_remap_msix_method() that effectively
broke the method as all the MSI-X table indices were off by one in
the backend MD code.
- Fix a cosmetic nit in the bootverbose printf in pci_alloc_msix_method().

Add missing 'break' that in this case is harmless.

As VPD support still causes hard hangs on boot with some hardware, add a
tunable allowing automatic parsing of VPD data to be disabled. The
default is left as-is; if you are having problems with hard hangs at boot
due to VPD, try setting hw.pci.enable_vpd=0. A proper architectural
solution has been under discussion for some time, but this allows me to
boot my test machines in the mean time.

Submitted by: bz
Head nod: jmg

Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating powerof2() messages for
example where MSI-X does not. To address this, split out the MSI-X
support from pci_msi_count() and pci_alloc_msi() into new driver-visible
functions pci_msix_count() and pci_alloc_msix(). As a result,
pci_msi_count() now just returns a count of the max supported MSI
messages for the device, and pci_alloc_msi() only tries to allocate MSI
messages. To get a count of the max supported MSI-X messages, use
pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix().
pci_release_msi() still handles both MSI and MSI-X messages, however.
As a result of this change, drivers using the existing API will only
use MSI messages and will no longer try to use MSI-X messages.
- Because MSI-X allows for each message to have its own data and address
values (and thus does not require all of the messages to have their
MD vectors allocated as a group), some devices allow for "sparse" use
of MSI-X message slots. For example, if a device supports 8 messages
but the OS is only able to allocate 2 messages, the device may make the
best use of 2 IRQs if it enables the messages at slots 1 and 4 rather
than default of using the first N slots (or indicies) at 1 and 2. To
support this, add a new pci_remap_msix() function that a driver may call
after a successful pci_alloc_msix() (but before allocating any of the
SYS_RES_IRQ resources) to allow the allocated IRQ resources to be
assigned to different message indices. For example, from the earlier
example, after pci_alloc_msix() returned a value of 2, the driver would
call pci_remap_msix() passing in array of integers { 1, 4 } as the
new message indices to use. The rid's for the SYS_RES_IRQ resources
will always match the message indices. Thus, after the call to
pci_remap_msix() the driver would be able to access the first message
in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at
SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based
rather than 0-based so that they will always correspond to the rid
values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt).
To support this API, a new PCIB_REMAP_MSIX() method was added to the
pcib interface to change the message index for a single IRQ.

Tested by: scottl

Disable MSI for the Intel 845 and 865 chipsets and update comment for
E7210 to note it is the same devid as the 875 chipset.

Fix the subvendor ID for PCI-PCI bridges.
- Retire the PCI_SUB*_1 constants and don't try to read a subvendor ID out
of them. There isn't a standard subvendor ID field for PCI-PCI bridges.
Instead, the dword at offset 0x34 is actually mostly reserved except for
the LSB which is the capabilities pointer.
- Add support for the PCI-PCI bridge subvendor ID capability (13) and use
it to set the subvendor ID for PCI-PCI bridges.

MFC after: 1 month

- Add a new flag to the PCI-PCI driver to disable MSI on devices behind the
bridge if it doesn't pass MSI messages up correctly. We set the flag
in pcib_attach() if the device ID is disabled via a PCI quirk.
- Disable MSI for devices behind the AMD 8131 HT-PCIX bridge. Linux has
the same quirk.

Tested by: no one despite repeated calls for testers

Disable MSI for two ServerWorks chipsets. The first is based on a user
report. The second is blacklisted in Linux.

Blacklist a few more Intel chipsets re: MSI based on user reports:
E7500 and 855.

- Condense the comment for Intel chipset MSI blacklist entries.
- Blacklist the E7210.

PR: kern/105768 (2)
Reported by: marcus (2)

Disable MSI on the Intel E7505 chipset. It is reported broken on a Tyan
S2665ANF motherboard.

Reported by: "Eugene M. Kim" <blue at white lv>

Disable MSI for the Intel E7501 chipset.

Reported by: jdp

Add a first pass at a way to blacklist MSI on systems where it doesn't
work:
- A new PCI quirk (PCI_QUIRK_DISABLE_MSI) is added to the quirk table.
- A new pci_msi_device_blacklisted() determines if a passed in device
matches an MSI quirk in the quirk table. This can be overridden (all
quirks ignored) by setting the hw.pci.honor_msi_blacklist to 0.
- A global blacklist check is performed in the MI PCI bus code by checking
to see if the device at 0:0:0 is blacklisted.

Tested by: jdp

Replace #define<space> with #define<tab> so the code is consistent with
style(9) and avoids mixing the two formats.

- Add constants for HT PCI capability registers including the various
subtypes of HT capabilities.
- Add constants for the MSI mapping window HT PCI capability.
- On i386 and amd64, enable the MSI mapping window on any HT bridges we
encounter and report any non-standard mapping window addresses.

Give the WREG() macro the same lifetime as the REG() macro.

Add some bootverbose printf's to detail how many MSI messages are allocated
and to which IRQs.

Requested by: scottl

don't mark the cksum as invalid here... off is incorrect when we get
here, it's either unset, or it's valid, so we don't need to do anything
different...

Reported by: Neterion (via rwatson)

Look for capabilities in PCI-PCI bridges using the same CAP PTR register
as for type 0 devices.

Submitted by: grehan
MFC after: 1 week

First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.

Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months

fix hanging on invalid data... (This doesn't fix hanging due to broken
hardware)...

Tested by: Ian Dowse, Adam K Kirchhoff and Vladimir Kushnir

Various whitespace cleanups.

Doh! Actually commit checking against NULL for res.

Noticed by: dougb@

Assign start to the value we were able to allocate and use that to
write out the BAR. Otherwise, we were trying to shift a 32-bit
quantity on 32-bit platforms. Also, 'start' check sanity to where it
is known.

More fully support 64-bit bars. Prior to this commit, we supported
only those bars that had addresses assigned by the BIOS and where the
bridges were properly programmed. Now even unprogrammed ones work.
This was needed for sun4v. We still only implement up to 2GB memory
ranges, even for 64-bit bars. PCI standards at least through 2.2 say
that this is the max (or 1GB is, I only know it is < 32bits).

o Always define pci_addr_t as uint64_t. A pci address is always 64-bits,
but some hosts can't address all of them.
o Preserve the upper half of the 64-bit word during resource probing.
o Test to make sure that 64-bit values can fit in a u_long (true on some
platforms, but not others). Don't use those that can't.
o minor pedantry about data sizes.
o Better bridge resource reporting in bootverbose case.
o Minor formatting changes to cope with different data types on different
platforms.

Submitted by: jmg, with many changes by me to fully support 64-bit
addresses.

fix tab indentation for CP and RV...

If the length is zero, catch this early, instead of making dflen go negative
and letting bad things happen... We also check to see if RV (checksum) is
0, and handle that has a checksum failure...

Properly handle checksum failures by not processing read-write VPD data,
and removing all the found read-only data...

Tested by: oleg (dflen going negative)

provide routines to access VPD data at the PCI layer...

remove sk's own implementation, and use the new calls to get the data...

Reviewed by: -arch

spell PCIS_CRYPTO_ENTERTAIN properly...

MFC after: 3 days

Simplify the pager support in DDB. Allowing different db commands to
install custom pager functions didn't actually happen in practice (they
all just used the simple pager and passed in a local quit pointer). So,
just hardcode the simple pager as the only pager and make it set a global
db_pager_quit flag that db commands can check when the user hits 'q' (or a
suitable variant) at the pager prompt. Also, now that it's easy to do so,
enable paging by default for all ddb commands. Any command that wishes to
honor the quit flag can do so by checking db_pager_quit. Note that the
pager can also be effectively disabled by setting $lines to 0.

Other fixes:
- 'show idt' on i386 and pc98 now actually checks the quit flag and
terminates early.
- 'show intr' now actually checks the quit flag and terminates early.

Fixup some comments to allow for the fact that PCI domains are not specific
to Alpha hoses.

The size of I/O ranges can be anything from 16 bytes to 2G bytes.
Lower the minimum for memory mapped I/O from 32 bytes to 16 bytes.
This fixes bus enumeration on ia64 now that the Diva auxiliary
serial port is attached to.

Make the 'pci_devclass' pointer variable private (drivers really shouldn't
share devclass pointers, a mistake I've encouraged in the past) and
move the declaration of the pci_driver kobj class from cardbus.c to
pci_private.h so that other drivers can inherit from pci_driver.

Use __HAVE_ACPI and __PCI_REROUTE_INTERRUPT as appropriate rather than
the complicated #ifdefs.

Remove stray debug from p4 integration.

Remove debug now that I've looped back the big changes into my p4 tree.

Expose pci_add_resources to the outside world, add a 'force' flag to
force allocation of unallocated BARs (cardbus uses this to preallocate
everything). Add a prefetchmask to allow for busses that get prefetch
hints to set them. Addjust pci_add_map and pci_ata_maps to take a new
force flag which pci_add_resources will pass in. Implement 'force' in
pci_add_map. Write new value of allocated resource into the bar, if
the allocation succeeded (we should have done this before, but with
the new force the bug was very obvious).

Add a new method PCI_FIND_EXTCAP() to the pci bus interface that is used
to search for a specific extended capability. If the specified capability
is found for the given device, then the function returns success and
optionally returns the offset of that capability. If the capability is
not found, the function returns an error.

Improve diagnostic message.

MFp4: When doing lazy allocation, it turns out that we need to record the
actual resource values we received from the system rather than the range
we requested. Since we request a range starting at 0, we would record
that number. Later, since this == 0, we'd allocate again. However,
we wouldn't write the new resource into the BAR. This resulted in
a resource leak as well as a BAR that couldn't access the resource at
all since rman_get_start, et al, were wrong.

MFC After: 1 week (assuming RELENG_6 is open for business)

Use symbolic name rather thanhard coding the cap pointer offset for
type two devices.

Minor style(9) nitage.

Add a 1 microsecond delay in pci_add_children(), right before the read
of the PCIR_HDRTYPE register. It's the value returned from this
read access that determines whether or not we decide a device is
present at the current slot index. For some reason that I can't
adequately explain, this read fails on my machine when probing the
USB controller on my machine (which happens a multifunction device
at slot index 3 hung off the PCI-PCI bridge on the AMD8111 (bus
index 1)). The read will return 0xFF even though it should return
0x80 to indicate the presence of a multifunction device.

As near as I can tell, there's some timing issue involved with reading
the 'dead' slot indexes 0 through 2 that causes the read of the actual
device at slot 3 to fail. I tried a couple of different tricks to
correct the problem (the patch to amd64/pci/pci_cfgreg.c fixes it
for the amd64 arch), but adding this delay is the only thing that
always allows the USB controllers to be correctly probed 100% of the
time. Whatever the problem is, it's likely confined to the AMD8111
chipset. However, a simple 1us delay is fairly harmless and should
have no side effects for other hardware. I consider this to be
voodoo, but it's fairly benign voodoo and it makes my USB keyboard
and mouse work again.

Note that this is the second time that I've had to resort to a
1us delay to fix a PCI-related problem with this AMD8111/Opteron
system (the first being a fix I made a while back to the NDISulator).
It's possible the delay really belongs in the cfgreg code itself,
or that pci_cfgreg needs some custom hackery for an errata in the
8111. (I checked but couldn't find any documented errata on AMD's
site that could account for these problems.)

- Consolidate duplicated code for assigning interrupts to PCI devices via
routing, etc. in a static pci_assign_interrupt() function.
- Add a sledgehammer that allows the user to override the interrupt
assignment of any PCI device via a tunable (e.g. "hw.pci0.7.INTB=5" would
force any functions on the pci device in slot 7 of bus 0 that use B# to
use IRQ 5). This should be used with great caution! Generally, if the
interrupt routing in use provides specific tunables (such as hard-wiring
the IRQ for a given $PIR or ACPI PCI link device), then those should be
used instead. One instance where this tunable might be useful is if a
box has an MPTable with duplicate entries for the same PCI device with
different IRQs.

MFC after: 1 week

Split power state control into two variables. hw.pci.do_powerstate
has been removed. It has been replaced by hw.pci.do_power_nodriver
and hw.pci.do_power_resume. The former defaults to 0 while the latter
defaults to 1.

When do_powerstate was set to 0, it broke suspend/resume for a lot of
people as an unintended consequence. This change will only affect the
areas that were intended to affect. This change will have no effect on
servers, but will help laptops quite a bit.

MFC After: 3 days.

Change hw.pci.do_powerstate from a boolean to a range. 0 means the
same as today: do no power management. 1 means be conservative about
what you power down (any device class that has caused problems gets
added here). 2 means be agressive about what gets powered down (any
device class that's fundamental to the system is here). 3 means power
them all down, reguardless. The default is 1.

The effect in the default system is to add mass storage devices to the
list that we don't power down. From all the pciconf -l lists that
I've seen for the aac and amr issue, the bad device has been a mass
storage device class.

This is an attempt at a compromise between the very small number of
systems that have extreme issues with powerdown, and the very large
number of systems that gain real benefits from powerdown (I get about
20% more battery life when I attach a minimal set of drivers on my
Sony). Hopefully it will strike the proper balance.

MFC After: 3 days (before next beta)

Allow one to access the cached values for CMDREG, CACHELNSZ, MINGNT,
MAXLAT and LATTIMER.

Improve error message when a bogus RID type is requested for a bar.

More consistantly return the correct BAR size. Before, we'd only
return the correct bar size if we encountered a 64-bit BAR that had
its resources already assigned. If the resources weren't yet
assigned, we'd bogusly assume it was a 32-bit bar and return 1.

Typo in comment.

Treat resources that are 0xfffff.... as being 'unassigned'.

Reviewed by: jhb
Tested by: Mark Kirkwood
MFC After: 3 days

Mask off the bar's value after the probe test write before testing
against 0 in pci_alloc_map, just like we do in pci_add_map. Also,
make sure that we restore the value to the BAR that was there before
if the bar is 0. Chances are that it was 0 before the write too and
that the restoration is a nop, but better safe than sorry.

Notice by: dwhite

Typo.

Submitted by: njl

Don't enable I/O or memory mode in a device's command register if the BAR
we are processing has a base address of zero. Note that this will only
change behavior for devices where all the BARs of a given type have a base
address of 0 since we will enable the appropriate access when we encounter
the first BAR with a base that is not 0. Specifically, this allows certain
Toshiba laptops to no longer require 'hw.pci.enable_io_modes=0' to avoid
hangs during boot.

PR: kern/20040
PR: i386/63776 (possibly)
PR: i386/68900 (possibly)
PR: i386/74532 (possibly)
MFC after: 1 week

Add a detach for pci bridge and pci bus drivers. This allows one to
theoretically unload pci bridges or pci drivers. It will also allow
detach to work if one needed to detach a subtree.

This is inspired by looking at the p4 commits from bms to his 5.4
tree, but I didn't look at the final results.

Call pci_print_verbose() before pci_add_resources() so that the order of
printf's during a verbose boot is more intuitive (the BAR listings and
interrupt routing info now comes after the config header dump rather than
just before it).

It isn't a whinable offence to want memory when the bar says ioport.
Put that behind bootverbose to make the ata driver less chatty on
advanced hardware.

Requested by: sos

Go ahead and try to allocate PCI_BAR(5) for ata devices.

move the statement about switching power states to just before we do it, so
we don't print a false statement if the destination powerstate is
unsupported...

add some additional pci classes and sub-classes..

Reviewed by: imp (almost 6 months ago)

relocate the power state transition statements to the
pci_set_powerstate_method function...

Reviewed by: imp
MFC after: 1 week

Use STAILQ in preference to SLIST for the resources. Insert new resources
last in the list rather than first.

This makes the resouces print in the 4.x order rather than the 5.x order
(eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x). This
also means that the pci code will once again print the resources in BAR
ascending order.

If bus_generic_susped returns an error, devlist is not freed. Free it.

Submitted by: Ted Unangst (using the Coverity Prevent analysis tool)

Expose pci_cfg_safe/restore for subclasses of pci to use.

kill unused variable

Noticed by: Coverity Prevent analysis tool

Enable interrupt routing as first choice on alpha.
The alpha default handler knows how to trigger a fallback.

Fix typo.

Start each of the license/copyright comments with /*-, minor shuffle of lines

Fix last second typos that crept in :-(.

Implement mimimum system software delays, per PCI PM 1.1 spec, as
suggested by Peter Edwards. This seems to fix my fxp problems and
likely will fix his as well. Use DELAY rather than *sleep because we
can be called from any context.

Fix comments to match last commit, and minor reformatting...

It turns out that a lot of newer systems have 'base peripherals' on
the PCI bus. We presently have no drivers for these devices, so they
are powered down. This is undesirable behavior since it breaks the
system when the base peripherals go away suddenly in the middle of
boot.

# if we ever get generic drivers for memory and/or base peripherals, then
# we can remove the tests here.

ACPI is not on pc98 either.

Informed by: nyan

Non-x86 platforms cannot use the ACPI includes. This should be fixed but
for now, only include the headers for i386, amd64, or ia64.

Pointed out by: grehan

Turn ACPI and PCI devices off or to a lower power state in suspend and
back on again in resume. Override the default of D3 with the value the
BIOS specifies in _SxD, if present. Skip serial devices (PNP05xx) since
they seem to hang when set to D3 and may require special driver support.
Also, skip non-type 0 PCI devices (i.e., bridges) since our we don't yet
save/restore their config space and that seems to be necessary.

If this gives you trouble with suspend/resume, you can disable the new
ACPI and PCI power behavior separately with these tunables & sysctls:
debug.acpi.do_powerstate
hw.pci.do_powerstate

Approved by: imp (pci)
Tested by: acpi@ (numerous)

Make pci_do_powerstate default to 1 now that we've done the release to
get more testing. This should help things a little.

- Change the ddb paging "support" to use a variable (db_lines_per_page) to
control the number of lines per page rather than a constant. The variable
can be examined and changed in ddb as '$lines'. Setting the variable to
0 will effectively turn off paging.
- Change db_putchar() to force out pending whitespace before outputting
newlines and carriage returns so that one can rub out content on the
current line via '\r \r' type strings.
- Change the simple pager to rub out the --More-- prompt explicitly when
the routine exits.
- Add some aliases to the simple pager to make it more compatible with
more(1): 'e' and 'j' do a single line. 'd' does half a page, and
'f' does a full page.

MFC after: 1 month
Inspired by: kris

Fix a spelling error in a panic string.

Re-route interrupts on arm as well.

Disable native ata support for now, too much breaks

Update the special handling code for ATA devices to allow usage of
PCI native addressing. That means that if the HW says that using "real"
addresses instead of the hardwired legacy compat ones is allowed, we will
use them.

Do the dreaded s/dev_t/struct cdev */
Bump __FreeBSD_version accordingly.

Use PCI_BAR() in preference to PCI_MAPS + x * 4.

Submitted by: jhb

Do not write to those config registers that are unambiguously defined
in the various pci specifications as readonly. vendor, subvendor,
device and subdevice are required to be loaded in hardware by some
means that isn't the system BIOS or other system software (although
some devices do have ways of accomplishing this). class and subclass
are defined to be read-only in section 6.2.1 (v2.2). Apart from the
status register, which we weren't touching, these are the only
read-only registers I could find in the 2.2 spec.

progif is also defined as being read-only in section 6.2.1. However,
the PCI IDE programming document specifically states that some of the
bits are read/write. Since we may have to restore registers before we
have a driver attached, go ahead and restore this one byte when
transitioning between D3 and D0.

The PCI spec also says that writes to reserved and unimplemented
registers must be completed normally. It makes no statements about
writes to read-only registers, so be as conservative as possible,
while covering the exception to the rule that is documented in a
subpart of the standard.

Requested by: socttl

Fix cutNpasto in last commit.

ifdef writing to registers that the base pci standard says are
read-only on D3->D0 power state transition. Add a define to enable
them, but include a comment to contact me if there's a problem.

Compeletely rewrite the description of hw.pci.do_powerstate to sound
better.

Improve the English somewhat.

Prodded by: ru@

Ooops, forgot to commit the updated definition for hw.pci.do_powerstate
when I committed code that changed its meaning.

MFp4:

Split the baby. For idepci devices, now both legacy mode bits need
not be set. We can run an idepci in a split mode. However, it only
works better than before, not works. It works better in that when one
device is legacy and the other isn't and disabled, we now operate
correctly.

sos submitted a version of this patch.

Move pci_do_powerstate up a level. Now it just means 'do not turn devices
off into d3 state when there's no driver for the device'. This should
help suspend/resume in the default case.

MFp4: o save/restore subvendor, subdevice, vendor, device, baseclass,
subclass, progif and revid. While these are typically read
only fields, they aren't always read-only. progif is writable
for ata devices, for example. It does no harm when they are
read only, and helps when they aren't.

make the pci power state and resource code a lot less chatty. The
chattiness was left in for debugging, but now that nearly all of the
problems relating to the changes have been fixed, it is only annoying. It
is still available via bootverbose.

Prodded by: jhb

Remove the EBus stopgap of r1.248; a proper fix is in place now.

Fix two typos from PR: 65694

1) In pci.c, we need to check the child device's state, not the parent
device's state.
2) In acpi_pci.c, we have to run the power state change after the acpi
method when the old_state is > new state, not the other way around.

Submitted by: Dmitry Remesov
PR: 65694

Add a stopgap for the EBus breakage on sparc64 since the PCI code does
resource pre-allocation. The problem is that the BARs of the EBus bridges
contain the ranges for the resources for the EBus devices beyond the bridge.
So when the EBus code tries to allocate the resource for an EBus device
it's already allocated by the PCI code.
To be removed again as soon as we have a proper solution in the EBus Code.

Reviewed by: tmm
Approved by: marcel (mentor)