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.

After talking with John, these two reports are self-consistent. The bridge see one kind of thing going on (timeout) while the card sees something else (bad header so ignored).

For example:
pciconf -bBlaec pcib5
pcib5@pci0:0:2:2: class=0x060400 card=0x083315d9 chip=0x6f068086 rev=0x01 hdr=0x01

  bus range  = 4-4
  window[1c] = type I/O Port, range 16, addr 0xf000-0xfff, disabled
  window[20] = type Memory, range 32, addr 0xfb500000-0xfb5fffff, enabled
  window[24] = type Prefetchable Memory, range 64, addr 0xfff00000-0xfffff, disabled
  cap 0d[40] = PCI Bridge card=0x083315d9
  cap 05[60] = MSI supports 2 messages, vector masks 
  cap 10[90] = PCI-Express 2 root port max data 256(256) ARI disabled
               link x4(x4) speed 2.5(8.0)
               slot 0 power limit 25000 mW surprise
  cap 01[e0] = powerspec 3  supports D0 D3  current D0
  ecap 000b[100] = Vendor 1 ID 2
  ecap 000d[110] = ACS 1
  ecap 0001[148] = AER 1 0 fatal 1 non-fatal 2 corrected
  ecap 000b[1d0] = Vendor 1 ID 3
  ecap 0019[250] = PCIe Sec 1 lane errors 0
  ecap 000b[280] = Vendor 1 ID 5
  ecap 000b[300] = Vendor 1 ID 8
PCI-e errors = Correctable Error Detected
               Non-Fatal Error Detected
   Non-fatal = Completion Timeout
   Corrected = Replay Timer Timeout
               Advisory Non-Fatal Error

For the commit, I'd suggest doing the injection tool (both userland and kernel) separate from the kernel changes to pcib.