Just 2014?

A comment explaining what these are for would be useful.

And these

What are these for?

Why do you need to use fdtbus_bs_tag here? It should only be used directly in the early boot code.

What is this magic number?

Why 0x3?

Magic 32?

0x3?

Why a delay of 1000?

Should be (regval & PEM_LINK_LT) != 0

Why not the following, but with a comment on why 3 is magic?

sli = sc->pem / 3;
sli_group = sc->pem % 3;
if (sli > 1)
  return (ENXIO);

What is a PEM number?

Magic numbers

retval != 0

Should be:

/*
 * This ...

Magic

Magic

Magic

Why does this address need to be translated?

It feels like you could extract the ecam value from the data.

Magic

Why do you need this file? We have been working on removing the need for it on other architectures.

Can you add a thunderx_pci option? It would allow for users to build a custom kernel with support for just the hardware they need.

So what is our current path? I thought we include all possible drivers to make a GENERIC kernel work on any arm64 hardware. Was there any change in priorities I'm not aware of?

Yes, GENERIC kernel should be able to run on any arm64 hardware. But users should also be able to compile a custom kernel without drivers they don't want. So in this case thunderx_pci would become an option, and GENERIC would have that option enabled.

Why is the I/O space ignored?

Should this be a KASSERT?

KASSERT?

Is this used?

It's not supported by internal PCIe controller. Will add a comment.

No, because KASSERTs can be disabled. These values are used to calculate an offset in #315 and I don't want to allow any access exceed ECAM space. That could corrupt PCIe registers and stay unnoticed for a long time.

Will remove.

I'd be a little worried that returning here might also mask a problem and thus leave it unnoticed.

I'll add device_printf here and below. I guess it will be the best compromise. The PCI spec tells to return 0xff...ff whenever the request is invalid so we be in-sync with it, and the user still could notice that something is not right.

The x86 code has returned -1 for this condition for a long time without a printf. I think this is fine as-is.

(See sys/amd64/pci/pci_cfgreg.c pcireg_cfgread() and pciereg_cfgread())

Please do not set bustag/handle in bus_alloc_resource() routines, but do it in a bus_activate_resource() method for this driver instead.