Clear BUSMASTEREN together with INTxDIS

Makes sense: ppt_teardown_msix_intr() -> bus_teardown_intr() -> pci_mask_msix() writes the vector control dword in the table BAR, so with decode off that is a UR. One suggestion: the old ordering also stopped DMA before the interrupt teardown (the device could still be bus-mastering while its guest mappings go away), and the new one leaves BUSMASTEREN on until afterwards. Clearing BUSMASTEREN together with INTxDIS first, and only deferring PORTEN/MEMEN until after the MSI-X teardown, keeps both properties. (MSI teardown doesn't touch BARs; only MSI-X does.) We carry the same ordering in keelOS's ppt (stable/15) and will pick this up.

handle PCI_QUIRK_MSI_INTX_BUG

Hmmm, so in theory device_detach() might power off the child. I guess that's ok. I have some WIP that will "fix" this more properly by having device_probe_and_attach() invoke a pre-probe bus_if.m method that for PCI restores the saved state that would handle this transparently, but this is ok for now.

LGTM + tested with ACPI and DT on MacchiatoBin.

• Rename quirk to PCIE_ECAM_DESIGNWARE_QUIRK
• Add socionext,synquacer-pcie-ecam and snps,dw-pcie-ecam compats

Yep that's another good observation... any more bugs you can think of with my original code? :)

Thinking about it again, pcib_expand_window() should receive not the requested start/end values, but MIN()/MAX() respectively from them and the current window base/limit. Otherwise in case of multiple resources pcib_expand_window() panic on attempt to shrink the window on another side of where it growth. Unfortunately I don't have hardware configuration with more than one second level bridge connected to the one closest to the root to illustrate that.

Still an accept with the context added :)

Given pcib_grow_window also rounds requests it seems sensible to be consistent and do so here too. Not writing the updated window is indeed a silly oversight and explains why clear_pcib wasn't working for me on my board, stopping enumeration early. But best wait for John to check there isn't something I'm overlooking here.

No longer working on this. Someone else can take it up.

This is fine.

Seems useful to me, especially as an interim solution for scanning for AER reports before we grow runtime support. Any objection @imp , @jhb ?

In D7697#197154, @imp wrote:

I'm reworking things to allow two types of usage. One by client devices that want to 'poll' their AER status and keep counts / records of what happened on that device. The second form is only on Root Complexes and Root Error Collection devices that collect records there (and maybe for root complexes walks the tree polling all the agents and endpoints involved to complete the record, if possible).

Errr, my cleanup is runtime, not ddb time, sorry for the confusion. I've not grabbed this code.

I've cleaned up this code somewhat, but not completely. I need to reconnect it to an interrupt and then test it in machines that generate these errors...

I like the idea of having this support in ddb, but will defer to @jhb and @imp.

Some more comments based on first trying to use this code, and then trying to rework it.
While the code is decently written, there's a number of fundamental assumptions it makes that aren't reflective of the AER in the PCIe spec that require changes.
I've not looked at all at the userland test suite, so have no opinion on that.