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

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

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

The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.

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

show more ...

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

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

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

The public bus_activate/deactivate_resource() API still accepts both
forms, but the internal kobj methods no longer pass the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.

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

show more ...

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_R

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

show more ...

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

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

show more ...

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

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

show more ...

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 sys

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

show more ...

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/D3

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

show more ...

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.
Spons

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

show more ...

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 devic

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

show more ...

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

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

show more ...

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 matchin

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

show more ...

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.

Sp

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

show more ...

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 co

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

show more ...

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

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

show more ...

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-

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

show more ...

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

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

show more ...

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

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

show more ...

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 board

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.

show more ...

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

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

show more ...

Implement pci_get_relaxed_ordering_enabled() helper function.

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