src/sys/dev/pci, branch releng/12.2

MFC r362661: Add mostly dummy hw.pci.enable_aspm tunable.

2020-08-07T17:32:53Z

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.

MFC r363624: Add initial driver for ACPI Platform Error Interfaces.

2020-08-07T01:05:10Z

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. Relnotes: yes Sponsored by: iXsystems, Inc.

MFC r362027 pci: loosen PCIe hot-plug requirements

2020-07-19T22:23:54Z

MFC r346386, r347890, r347896, r349895:

2020-07-08T17:59:00Z

remove the 4GB boundary requirement on PCI DMA segments

MFC r347440, r347929-r347930, r349588

2020-06-16T20:35:01Z

r347440: ahci: Check if bus is cache-coherent We do this for FDT systems but not for ACPI ones. Check the presence of the _CCA attribute. Sponsored by: Ampere Computing, LLC Reviewed by: andrew Differential Revision: https://reviews.freebsd.org/D20144 r347929: pci: ecam: Do not warn on mismatch of bus_end We cannot know the bus end number before parsing the MCFG table so don't set the bus_end before that. If the MCFG table doesn't exist we will set the configuration base address based on the _CBA value and set the bus_end to the maximal number allowed by PCI. Sponsored by: Ampere Computing, LLC Differential Revision: https://reviews.freebsd.org/D20213 r347930: pci: ecam: Correctly parse memory and IO region When activating a resource do not compare the resource id to the adress. Treat IO region as MEMORY region too. Submitted by: Tuan Phan (Original Version) Sponsored by: Ampere Computing, LLC Differential Revision: https://reviews.freebsd.org/D20214 r349588: arm64: efi: Map memory IO region as device Reviewed by: andrew Sponsored by: Ampere Computing, LLC

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

2020-06-12T07:25:40Z

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.

MFC r350571:

2020-05-11T20:10:01Z

Fix the build after r350570. Signed char cannot compare to values above 0x7f. Use unsigned instead.

MFC r346645, r346664, r346687, r347387, r347836, r347088, 347089, r346956,

2020-05-01T09:46:27Z

r346957, r346958, r347088, r347089, r347385, r353938, r350570, r350572 and r350573: Implement full bus_dma(9) support in the LinuxKPI and pull in all dependencies. Bump FreeBSD version to force recompilation of external modules. Sponsored by: Mellanox Technologies

MFC r351514: Don't consider PCIe hot-plug command timeout fatal.

2020-04-24T16:39:34Z

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 r359057:

2020-03-26T00:39:36Z

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@ Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D23679