pci: bcm2838: cleanup on attach failure to fix devmatch panic

[kevans]

Summary

Specifically on the RPi CM4, we currently don't set the controller up
right and it never moves into the ready state (we don't observe the link
active bit). Failure to cleanup here actually results in a panic not
long after, due to a use-after-free in the rman bits. Further down in
pci_host_generic, we have some rman stashed in the softc that are
initialized and placed onto the rman tailq, then the softc is later
freed without an rman_fini() to pull them off of the tailq properly.

Note that PCI-E on this board still isn't functional after this patch,
but it does at least allow the board to boot out of the box without
having to disable devmatch.

Shout-out to Vince <[e-mail]> for the extensive debugging and
analysis to arrive at this conclusion.

[freebsd_darkain.com]

An update for the commit message.

Yes, PCIe is working!

My initial testing was with a specific Broadcom PCIe NIC. The CM4 for whatever reason doesn't like this NIC. I have two of them, both fail on this board. They were tested directly in the board itself, and through a PCIe switch between them and the board. However, further testing, virtually everything is working. This includes the mentioned PCIe switch, XHCI/USB3 card, multiple Intel NICs, Emulex NICs, Realtek NICs, and Intel Optane NVMe.

Our initial assumption of "PCIe doesnt work even with this patch" was wrong because I was only testing with what appears to be a single incompatible card.

Otherwise, with this patch, the CM4 now properly boots up without boot-looping anymore if no PCIe device is available!

[kevans]

In D56897#1303819, @freebsd_darkain.com wrote:

An update for the commit message.

Yes, PCIe is working!

My initial testing was with a specific Broadcom PCIe NIC. The CM4 for whatever reason doesn't like this NIC. I have two of them, both fail on this board. They were tested directly in the board itself, and through a PCIe switch between them and the board. However, further testing, virtually everything is working. This includes the mentioned PCIe switch, XHCI/USB3 card, multiple Intel NICs, Emulex NICs, Realtek NICs, and Intel Optane NVMe.

Our initial assumption of "PCIe doesnt work even with this patch" was wrong because I was only testing with what appears to be a single incompatible card.

Otherwise, with this patch, the CM4 now properly boots up without boot-looping anymore if no PCIe device is available!

How about replacing that pargagraph with:

Note that PCIe on this board won't come up at boot without something                                            
plugged in, so it currently can't be booted with an empty slot with the                                         
intent to hotplug a supported card.  Some issues with controller startup                                        
have been observed with Broadcom NICs in the wild, but no problems have                                         
been observed with other NICs and a variety of different PCIe cards.