ofw_pci_driver should be subclassed by other drivers instead of exporting its methods

Changes after internal review:

• Remove structures for unsupported PAXB/PAXC V2 revisions - they won't be probed
• Derive from ofw_pci_driver instead of exporting its methods
• Make explicit apb_err_disable/enable functions
• Simplify some code

Clear the mapping in pmap_unmapbios as suggested.

Add fix for race condition in pmap_unmapbios() which I forgot to add earlier.

I wrote an alternative, more complete implementation of mapbios/unmapbios functions without any of the previous caveats.
Of course the code got a little more complicated but I think it's still comprehensible.
@andrew let me know what you think.

More context.

In D15059#317300, @andrew wrote:

Can you provide more context. If you are uploading a patch via the web interface there are instructions on the wiki to ensure this is the case at https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

In D14437#309219, @nwhitehorn wrote:

I think there is also a subtlety for uncaught signals if the previous trap was a kernel fault, since you then end up in the wrong branch of the kernel/user if in trap() and probably crash.

In any case, I think the simplest solution is to have a replacement for trapcode that does the same things as trapcode, but additionally moves hsrr0/hsrr1 into srr0/srr1. Until we try to support bhyve, which is a larger project, they are safe to clobber in this context. trapcode is currently using 7 of a possible 32 instructions, so adding a variant with four more (mfhsrr0 %r1; mtsrr0 %r1; mfhsrr1 %r1; mtsrr1 %r1) in the middle should be fine. That also avoids the need for hrfid and related things when returning. We would then just install the variant for traps like HEA that are known to set HSRR* instead of SRR* and keep the rest of the trap-handling code as-is.

I have no access to HW currently so cannot check this, but it seems you're right. I did not think of the case where userspace catches the signal.

In D14703#309190, @imp wrote:

Having looked closely, though, it appears that it relies on it only for single byte quantities

In D14437#309033, @nwhitehorn wrote:

I'm looking at this again. Does this actually work? HEA interrupts set HSRR0/HSSR1, which we don't save, so I think this will jump back to some random other memory location (whatever happened to be in SRR0).

As wma said, we'll make a follow-up commit fixing BE.

Unfortunately I'm not able to test this today and provide a patch but I think what needs to be done is:

• include <sys/endian.h>
• add htole32() for in.nsid and also for every cdwXX field
• call nvme_completion_swapbytes() before reading cdw0

Doesn't work on big-endian, I'll work on a fix.

As suggested, I have reworked the patch to perform endianess conversions all at once and as early as possible. The changes concern data which is read from device. I've also implemented other suggestions from the review.

It's done that way because I needed to maintain a strict convention of where byte-swapping was performed to minimize the chance of mistakes (such as forgetting to swap or double-swapping a field by mistake as it's passed through various callbacks). Otherwise it was hard to make sense of the code, as there are a lot of fields which need swapping and they are often transferred throughout components.

Rebase to latest HEAD

Rebase to latest HEAD

Change MSI-X number allocation scheme to make use of vmem_alloc() instead of local bitmap.

Move the code to a separate function gic_map_msi() similarly to D7698.

In D7568#162015, @wma wrote:

My only concern is if we can move this part of code to another file, like gicv3_fdt, where we have xref stuff already. In the present shape it fails to compile when FDT support is disabled.

Move xref registration to gic_v3_fdt.c

Add missing Serdes DTS node and include the driver in files.arm and files.arm64.

Return error when MSI could not be registered.

Add $FreeBSD$, cleanup mutex locks in detach(), check if mtx is initialized before calling lock/unlock.

Move MSIX file entry from sys/conf/files to files.arm and files.arm64. Add fdt dependency.

Move al_pci device entry from sys/conf/files to files.arm and files.arm64. Add fdt dependency.

Move the code to a new function gic_map_msi() and call it in gic_map_intr() switch case for MSI. No functional changes.

obsolete.

obsolete.

obsolete.

obsolete.

obsolete.

obsolete.

obsolete.

Add comments describing added devices in kernel conf.

Fix style issues raised in review.

Rework MSI-X allocation to suit post-D7493 INTRNG.
I also removed some oddities leftover from old versions of the driver and simplified the code.

Remove implementation of bus_extend_resource() which is no longer in tree. Alpine MSI-X interrupts work fine without it after D7493 and a small change in GICv3.

In D7568#157092, @andrew wrote:

Why do you need to retrieve this? It's normally done through INTRNG.

Updated base file version - no change in added code.

Use device entry instead of SOC option.

Use device entries instead of SOC option.

Use device entries instead of SOC option.

Use device entries al_ccu and al_nb_service instead of SOC option.

In D7562#157063, @emaste wrote:

I'm curious why these are options, and not just device entries?

I'm abandoning this revision as bus_extend_resource has been removed in rS304459 (D7493).

In D7567#157144, @nwhitehorn wrote:

How does this interact with D7493? That change removes this method entirely.

I'm also dubious about using this kind of method with MSI for the reasons mentioned earlier: the bus API deal with IRQ numbers, rather than struct resource *, and so bus_extend_resource() has some nasty corner cases. I have some comments on this in the driver revision (D7571).

Remove all no-INTRNG parts of PCI driver.

Remove non-INTRNG parts of the driver as they are no longer necessary.

In D7579#157268, @andrew wrote:

However, I can remove it if INTRNG is to stay.

There is no way to disable INTRNG and get a working arm64 kernel.