Commit Graph

139 Commits

Author SHA1 Message Date
Andriy Gapon
12588ce02d PCI hot-plug: use dedicated taskqueue for device attach / detach
Attaching and detaching devices can be heavy-weight and detaching can
sleep waiting for events.  For that reason using the system-wide
single-threaded taskqueue_thread is not really appropriate.
There is even a possibility for a deadlock if taskqueue_thread is used
for detaching.

In fact, there is an easy to reproduce deadlock involving nvme, pass
and a sudden removal of an NVMe device.
A pass peripheral would not release a reference on an nvme sim until
pass_shutdown_kqueue() is executed via taskqueue_thread.  But the
taskqueue's thread is blocked in nvme_detach() -> ... -> cam_sim_free()
because of the outstanding reference.

MFC after:	10 days
Sponsored by:	CyberSecure
Reviewed by:	mav, imp
Differential Revision:	https://reviews.freebsd.org/D30144
2021-05-06 21:49:37 +03:00
Mateusz Guzik
04e8183fd1 pci: clean up empty lines in .c and .h files 2020-09-01 22:00:07 +00:00
Chuck Tuffli
f14f005113 pci: loosen PCIe hot-plug requirements
The original PCIe hot-plug code required a couple of things which cause
PCI probing errors on the QEMU Q35 system and possibly physical systems
(Dell R6515).

Allocate the hot-plug interrupt as shared to support INTx interrupts.
The hot-plug interrupt mechanism should normally be MSI as PCIe mandates
MSI support, but QEMU's Q35 bridge only provides INTx interrupts.

Second, the code required the Electromechanical Interlock (Slot Status
EIS) to be engaged if present (Slot Capability EIP). Some platforms
including QEMU Q35 set EIP but not EIS. Fix by deleting the check.

Reviewed by: imp, mav, jhb
MFC after:	2 weeks
Differential Revision: https://reviews.freebsd.org/D24877
2020-06-10 20:12:45 +00:00
Andriy Gapon
cffd37da23 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
2020-05-29 07:50:55 +00:00
Scott Long
13d700adec Abstract the locking for PCIe hotplug. It still uses Giant so there's
no functional change yet.
2019-12-26 21:00:06 +00:00
Alexander Motin
21e51c82fb Don't consider PCIe hot-plug command timeout fatal.
According to my tests and errata to several generations of Intel CPUs,
PCIe hot-plug command completion reporting is not very reliable thing.
At least on my Supermicro X11DPi-NT board I never saw it reported.
Before this change timeout code detached devices and tried to disable
the slot, that in my case resulted in hot-plugged device being detached
just a second after it was successfully detected and attached.  This
change removes that, so in case of timeout it just prints the error and
continue operation.  Linux does the same.

MFC after:	1 week
Sponsored by:	iXsystems, Inc.
2019-08-26 17:27:36 +00:00
Colin Percival
e0235fd34a Only respond to the PCIe Attention Button if a device is already plugged in.
Prior to this commit, if PCIEM_SLOT_STA_ABP and PCIEM_SLOT_STA_PDC are
asserted simultaneously, FreeBSD sets a 5 second "hardware going away" timer
and then processes the "presence detect" change. In the (physically
challenging) case that someone presses the "attention button" and inserts
a new PCIe device at exactly the same moment, this results in FreeBSD
recognizing that the device is present, attaching it, and then detaching it
5 seconds later.

On EC2 "bare metal" hardware this is the precise sequence of events which
takes place when a new EBS volume is attached; virtual machines have no
difficulty effecting physically implausible simultaneity.

This patch changes the handling of PCIEM_SLOT_STA_ABP to only detach a
device if the presence of a device was detected *before* the interrupt
which reports the Attention Button push.

Reported by:	Matt Wilson
Reviewed by:	jhb
MFC after:	1 week
Sponsored by:	https://www.patreon.com/cperciva
Differential Revision:	https://reviews.freebsd.org/D20499
2019-06-05 04:58:42 +00:00
Conrad Meyer
e2e050c8ef 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.
2019-05-20 00:38:23 +00:00
Konstantin Belousov
5db2a4a812 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
2019-04-05 19:25:26 +00:00
Justin Hibbits
bfed756af6 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
2018-12-04 04:55:49 +00:00
Justin Hibbits
5502348d9a Only conform to PCIe spec of 1 device per bus on !x86
bhyve's root PCI complex shows up as PCIe, but behaves as traditional PCI.
Until that is special cased in a root complex driver, leave x86 as it was.

Requested by:	grehan
2018-05-30 22:39:41 +00:00
Justin Hibbits
8b92ad4371 Restrict PCIe maxslots to 0, instead of PCI_SLOTMAX
Summary:
PCIe only permits 1 device on an endpoint, so some devices ignore the device
part of B:D:F probing.  Although ARI likely fixes this, not all platforms
support ARI completely or correctly, so some devices end up showing up 32
times on the bus.

This was found during bringup of POWER9/Talos, and has been tested on POWER9
and POWER8 hardware.

Reviewed by:	leitao
Differential Revision: https://reviews.freebsd.org/D15461
2018-05-30 02:41:47 +00:00
Alexander Kabaev
151ba7933a 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
2017-12-25 04:48:39 +00:00
Pedro F. Giffuni
718cf2ccb9 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.
2017-11-27 14:52:40 +00:00
John Baldwin
1ffd07bde6 Various fixes for PCI _OSC handling so HotPlug works again.
- Rename the default implementation of 'pcib_request_feature' and add
  a pcib_request_feature() wrapper function (as is often done for
  new-bus APIs implemented via kobj) that accepts a single function.
  Previously the call to pcib_request_feature() ended up invoking the
  method on the great-great-grandparent of the bridge device instead
  of the grandparent.  For a bridge that was a direct child of pci0 on
  x86 this resulted in the method skipping over the Host-PCI bridge
  driver and being invoked against nexus0
- When invoking _OSC from a Host-PCI bridge driver, invoke
  device_get_softc() against the Host-PCI bridge device instead of the
  child bridge that is requesting HotPlug.  Using the wrong softc data
  resulted in garbage being passed for the ACPI handle causing the
  _OSC call to fail.
- While here, perform some other cleanups to _OSC handling in the ACPI
  Host-PCI bridge driver:
  - Don't invoke _OSC when requesting a control that has already been
    granted by the firmware.
  - Don't set the first word of the capability array before invoking
    _OSC.  This word is always set explicitly by acpi_EvaluateOSC()
    since it is UUID-independent.
  - Don't modify the set of granted controls unless _OSC doesn't exist
    (which is treated as always successful), or the _OSC method
    doesn't fail.
  - Don't require an _OSC status of 0 for success.  _OSC always
    returns the updated control mask even if it returns a non-zero
    status in the first word.
  - Whine if _OSC ever tries to revoke a previously-granted control.
    (It is not supposed to do that.)
- While here, add constants for the _OSC status word in acpivar.h
  (though currently unused).

Reported by:	adrian
Reviewed by:	imp
MFC after:	1 week
Tested on:	Lenovo x220
Differential Revision:	https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
Gavin Atkinson
5914c62e1f Fix spelling mistake in comment, firmwrae -> firmware 2017-02-28 23:55:03 +00:00
Warner Losh
28586889c2 Convert PCIe Hot Plug to using pci_request_feature
Convert PCIe hot plug support over to asking the firmware, if any, for
permission to use the HotPlug hardware. Implement pci_request_feature
for ACPI. All other host pci connections to allowing all valid feature
requests.

Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
Warner Losh
8a1926c5c1 Rename pci_pcie_intr to pci_pcie_intr_hotplug.
Sponsored by: Netflix
2017-02-25 06:11:50 +00:00
Warner Losh
4cb6772936 Create pcib_request_feature.
pcib_request_feature allows drivers to request the firmware (ACPI)
release certain features it may be using. ACPI normally manages things
like hot plug, advanced error reporting and other features until the
OS requests ACPI to relenquish control since it is taking over.

Sponsored by: Netflix
2017-02-25 06:11:36 +00:00
Eric van Gyzen
3729014801 PCIe HotPlug: remove tests for DL active link capability
As of r313097, the HotPlug code requires the link to support
reporting of the data-link status.  Remove tests for this capability
from code that can now assume its presence.

Suggested by:	jhb
Reviewed by:	jhb
MFC after:	3 days
Sponsored by:	Dell EMC
Differential Revision:	https://reviews.freebsd.org/D9431
2017-02-04 00:34:00 +00:00
John Baldwin
2ffb582a45 Require Data Layer Active reporting for native PCI-e HotPlug.
Some PCI-e bridges report that they support HotPlug in the slot
capabilities but do not report support for Data Layer Active events
in the link capabilities register.  These bridges do not work correctly
when HotPlug is used.  Further, while the description of HotPlug in
the spec does not mention that DL active events are required, the
description of the link capabilities register says that DL active is
required for HotPlug.  Thanks to Dave Baukus for finding that language
in the spec.

PR:		211699
Submitted by:	Dave Baukus <daveb@spectralogic.com>
Reviewed by:	vangyzen
MFC after:	3 days
2017-02-02 17:29:15 +00:00
Eric van Gyzen
991d431fa8 PCIe HotPlug: Detect bridges that are not really HotPlug capable
Some devices report that they have an MRL when they actually
do not.  Since they always report that the MRL is open, child
devices would be ignored.  Try to detect these devices and
ignore their claim of HotPlug support.  Specifically,
if there is an open MRL but the Data Link Layer is active,
the MRL is not real.

Revert r303645 to re-enable HotPlug support for slots with
power controllers, since it works correctly in my testing.

Start the DLL state-change timer if Presence /or/ MRL state changes,
along with other conditions.  Previously, we started the timer iff
Presence changed.  If there is an MRL, it must be closed for power
to be turned on, so Presence is unlikely to change on an MRL-close event.

Add a printf() of interesting registers on HotPlug interrupts and
commands (one from erj@).  These were very useful for debugging.
Guard them with bootverbose, since they're spam in normal operation.

In collaboration with:	jhb
Reviewed by:	jhb
MFC after:	1 day
Relnotes:	yes (re-enable HotPlug support for slots with power controllers)
Sponsored by:	Dell Inc.
Differential Revision:	https://reviews.freebsd.org/D7509
2016-08-17 01:24:34 +00:00
Eric van Gyzen
a1566487db Fix some logic in PCIe HotPlug; display EI status
The interpretation of the Electromechanical Interlock Status was
inverted, so we disengaged the EI if a card was inserted.
Fix it to engage the EI if a card is inserted.

When displaying the slot capabilites/status with pciconf:

- We inverted the sense of the Power Controller Control bit,
  saying the power was off when it was really on (according to
  this bit).  Fix that.

- Display the status of the Electromechanical Interlock:
        EI(engaged)
        EI(disengaged)

Reviewed by:	jhb
MFC after:	3 days
Sponsored by:	Dell Inc.
Differential Revision:	https://reviews.freebsd.org/D7426
2016-08-05 23:23:48 +00:00
John Baldwin
2611037c1c Disable PCI hotplug support for slots with power controllers.
After further review of the spec, I do not think the current HotPlug
code handles slots with power controllers correctly.  In particular,
the power state of the slot is to be inferred from other events, not
from examining the state of the power control bit in SLOT_CTL.  For now,
disable PCI hotplug support on such slots.

PR:		211081
Tested by:	Jeffrey E Pieper <jeffrey.e.pieper@intel.com>
MFC after:	3 days
2016-08-01 22:19:23 +00:00
Bjoern A. Zeeb
6ca2d09437 Try to declare _hw_pci for all sysctl cases needed after r303497.
MFC after:	5 days
X-MFC with:	r303497
2016-07-30 20:31:12 +00:00
John Baldwin
25a57bd64b Add a loader tunable (hw.pci.enable_pcie_hp) to disable PCI-e HotPlug.
Some systems and/or devices (such as riser cards) do not include a
non-compliant implementation of PCI-e HotPlug that can result in devices
not being attached (e.g. the HotPlug code might assume that a card is
being unplugged and will power the slot off and detach it).  This
tunable can be set to 0 to disable support for PCI-e HotPlug ignoring
the incorrect HotPlug state on these slots.

PR:		211081
Reported by:	Sergey Renkas <serg_ic@mail.ru> (SuperMicro X7 riser card)
Reported by:	Jeffrey E Pieper <jeffrey.e.pieper@intel.com>
	 	(Intel X520 adapter)
MFC after:	1 week
Relnotes:	yes
2016-07-29 17:54:21 +00:00
John Baldwin
6f33eaa5f0 Implement a proper detach method for the PCI-PCI bridge driver.
- Add a pcib_detach() function for the PCI-PCI bridge driver.  It
  tears down the NEW_PCIB and hotplug state including destroying
  resource managers, deleting child devices, and disabling hotplug
  events.
- Add a detach method to the ACPI PCI-PCI bridge driver which calls
  pcib_detach() and then frees the copy of the _PRT interrupt routing
  table.
- Add a detach method to the PCI-Cardbus bridge driver which frees
  the PCI bus resources in addition to calling cbb_detach().
- Explicitly clear any pending hotplug events during attach to ensure
  future events will generate an interrupt.
- If a the Command Completed bit is set in the slot status register
  when the command completion timeout fires, treat it as if the
  command completed and the completion interrupt was just lost rather
  than forcing a detach.
- Don't wait for a Command Completed notification if Command Completion
  interrupts are disabled.  The spec explicitly says no interrupt is
  enabled when clearing CCIE, and on my T400 no interrupt is generated
  when CCIE is changed from cleared to set, either.  In addition, the
  T400 doesn't appear to set the Command Completed bit in the cases
  where it doesn't generate an interrupt, so don't schedule the timer
  either.  (If the CC bit were always set, one could always set the timer
  and rely on the logic of treating CC set as a missed interrupt.)

Reviewed by:	imp (older version)
Differential Revision:	https://reviews.freebsd.org/D6424
2016-05-20 00:03:22 +00:00
John Baldwin
07454911f0 Rework managing hotplug commands with command completions.
Previously the command completion interrupt would post any pending
command immediately before pcib_pcie_hotplug_update() had been
run to inspect the current status.  Now, the command completion
interrupt merely clears the flag and stops the timer assuming that
the caller is always going to call pcib_pcie_hotplug_update() to
generate the next hotplug command if one is needed.

While here, fix a bug for systems with command completion where the
old (existing) value was written to the slot control register instead
of the new value.  This fixes the complaint about a missing hotplug
interrupt on my T400.

Differential Revision:	https://reviews.freebsd.org/D6363
2016-05-17 19:48:28 +00:00
Andrew Turner
1e43b18c4b Add a pcib interface for use by interrupt controllers that need to
translate the pci rid to a controller ID. The translation could be based
on the 'msi-map' OFW property, a similar ACPI option, or hard-coded for
hardware lacking the above options.

Reviewed by:	wma
Obtained from:	ABT Systems Ltd
Sponsored by:	The FreeBSD Foundation
2016-05-16 09:31:44 +00:00
Andrew Turner
d7be980dbe 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
2016-05-16 09:15:50 +00:00
Conrad Meyer
f41be0f076 Revert r299467 to fix the kernel build.
$ svn merge -c -299467 .

Approved by:	build being broken for six hours
2016-05-11 23:00:12 +00:00
Andrew Turner
9a36a337ff 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
2016-05-11 17:07:29 +00:00
John Baldwin
82cb5c3b5b Native PCI-express HotPlug support.
PCI-express HotPlug support is implemented via bits in the slot
registers of the PCI-express capability of the downstream port along
with an interrupt that triggers when bits in the slot status register
change.

This is implemented for FreeBSD by adding HotPlug support to the
PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges
representing downstream ports on HotPlug slots. The PCI-PCI bridge
driver registers an interrupt handler to receive HotPlug events. It
also uses the slot registers to determine the current HotPlug state
and drive an internal HotPlug state machine. For simplicty of
implementation, the PCI-PCI bridge device detaches and deletes the
child PCI device when a card is removed from a slot and creates and
attaches a PCI child device when a card is inserted into the slot.

The PCI-PCI bridge driver provides a bus_child_present which claims
that child devices are present on HotPlug-capable slots only when a
card is inserted. Rather than requiring a timeout in the RC for
config accesses to not-present children, the pcib_read/write_config
methods fail all requests when a card is not present (or not yet
ready).

These changes include support for various optional HotPlug
capabilities such as a power controller, mechanical latch,
electro-mechanical interlock, indicators, and an attention button.
It also includes support for devices which require waiting for
command completion events before initiating a subsequent HotPlug
command. However, it has only been tested on ExpressCard systems
which support surprise removal and have none of these optional
capabilities.

PCI-express HotPlug support is conditional on the PCI_HP option
which is enabled by default on arm64, x86, and powerpc.

Reviewed by:	adrian, imp, vangyzen (older versions)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D6136
2016-05-05 22:26:23 +00:00
John Baldwin
67e7d085ae Add a pcib_attach_child() method to manage adding the child "pci" device.
This allows the PCI-PCI bridge driver to save a reference to the child
device in its softc.

Note that this required moving the "pci" device creation out of
acpi_pcib_attach().  Instead, acpi_pcib_attach() is renamed to
acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI
interrupt routing table.

Differential Revision:	https://reviews.freebsd.org/D6021
2016-04-27 16:39:05 +00:00
Justin Hibbits
da1b038af9 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
2016-03-18 01:28:41 +00:00
Justin Hibbits
534ccd7bbf 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
2016-03-03 05:07:35 +00:00
Justin Hibbits
c47476d7e6 Migrate many bus_alloc_resource() calls to bus_alloc_resource_anywhere().
Most calls to bus_alloc_resource() use "anywhere" as the range, with a given
count.  Migrate these to use the new bus_alloc_resource_anywhere() API.

Reviewed by:	jhb
Differential Revision:	https://reviews.freebsd.org/D5370
2016-02-27 03:38:01 +00:00
Justin Hibbits
89977ce227 Convert a few more long -> rman_res_t. 2016-02-16 17:55:10 +00:00
Justin Hibbits
2dd1bdf183 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
2016-01-27 02:23:54 +00:00
John-Mark Gurney
bee4a63bb7 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..
2015-10-18 08:13:51 +00:00
Zbigniew Bodek
18c72666ce Add domain support to PCI bus allocation
When the system has more than a single PCI domain, the bus numbers
are not unique, thus they cannot be used for "pci" device numbering.
Change bus numbers to -1 (i.e. to-be-determined automatically)
wherever the code did not care about domains.

Reviewed by:   jhb
Obtained from: Semihalf
Sponsored by:  The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3406
2015-09-16 23:34:51 +00:00
Zbigniew Bodek
4718610d0d Treat internal bridge as subtractive on ThunderX ARM64
Internal bridges in Cavium ThunderX SoC behave as subtractive,
but they are unable to be identified. Force setting an appropriate
flag.

Reviewed by:   emaste, imp
Obtained from: Semihalf
Sponsored by:  The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3277
2015-08-08 21:46:38 +00:00
Marcel Moolenaar
b7cbd25b77 Revert previous change. The magical constants can't be changed
(easily) without having to go to other drivers to change the
magical return values. This wouldn't be so bad if there were
proper defines for these constants.

In particular dev/acpica/acpi_pcib_pci.c returns -1000 as the
probe priority and it's expected that this driver gets to
attach over the common PCI bus drivers.
2015-06-06 17:04:36 +00:00
Marcel Moolenaar
bbb169f2a4 Don't return -10000 as the probe priority. That's lower than what
BUS_PROBE_HOOVER is. Drivers like proto(4), when compiled into the
kernel or preloaded, will render your system useless by virtue of
attaching to your PCI busses.

Return BUS_PROBE_GENERIC instead. It's just the next priority up
from BUS_PROBE_HOOVER. No other meaning has been give to its use.
While BUS_PROBE_DEFAULT seems like a better candidate, it's hard
not to think that there must be some reason why these drivers
return -10000 in the first place.

Differential Revision:	D2705
2015-06-06 15:51:11 +00:00
Justin Hibbits
809923ca02 Add a PCI bridge for the Freescale PCIe Root Complex
Summary:
The Freescale PCIe Root Complex shows up as a Processor class device, PowerPC
subclass, so the generic PCI code ignores it for a bridge.  This adds support
for it.

As part of this, update the Freescale PCI hostbridge driver, to allow probing
beyond the root complex, instead of only allowing "proper" PCI-PCI bridges.

Reviewers: #powerpc, marcel, nwhitehorn

Reviewed By: nwhitehorn

Subscribers: imp

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

Relnotes:	yes
2015-05-11 20:58:05 +00:00
John Baldwin
ad6f36f845 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
2015-04-22 22:02:27 +00:00
John Baldwin
7212fc6a34 Don't explicitly manage power states for PCI-PCI bridge devices in the
driver's suspend and resume routines.  These have been redundant no-ops
since r214065 changed the PCI bus driver to manage power states for
all devices (including type 1/2 bridge devices) during suspend and resume.
2015-04-22 21:56:44 +00:00
John Baldwin
2ae5fd151f Fix some incorrect #if conditions around older workarounds for bus
numbering goofs.

MFC after:	1 week
2015-04-22 21:47:51 +00:00
Ryan Stone
2397d2d817 Add some pcib methods to get ARI-related information
Differential Revision:	https://reviews.freebsd.org/D72
Reviewed by:		jhb
MFC after: 		1 month
Sponsored by:		Sandvine Inc.
2015-03-01 00:39:40 +00:00
John Baldwin
0e521c9a26 Pass a valid Dx state variable to PCIB_POWER_FOR_SLEEP() in pcib_resume()
instead of NULL.

Submitted by:	dchagin
MFC after:	2 weeks
2015-01-25 19:53:09 +00:00