👍

... leaving just arm (which still enables it for GENERIC and TEGRA124) and mips
(which still enables it for RT2880_FDT and various std.mediatek-using kernel
configs), ...

For everything that already had NEW_PCIB, this change is a no-op, obviously. But what about those configs which haven't had NEW_PCIB until now? Presumably the reason they didn't have it until now is because there was some incompatibility with NEW_PCIB, but I don't see anything which would resolve those issues.

In D32954#743964, @rpokala wrote:

... leaving just arm (which still enables it for GENERIC and TEGRA124) and mips
(which still enables it for RT2880_FDT and various std.mediatek-using kernel
configs), ...

For everything that already had NEW_PCIB, this change is a no-op, obviously. But what about those configs which haven't had NEW_PCIB until now? Presumably the reason they didn't have it until now is because there was some incompatibility with NEW_PCIB, but I don't see anything which would resolve those issues.

All the pcib drivers in sys/arm support NEW_PCIB as far as I can tell, by virtue of deriving from either ofw_pcib_driver or generic_pcie_fdt_driver, or implementing support themselves like mv_pci. And the only board not supposedly supported by GENERIC whose board-specific kernel config enables device pci is ALPINE, whose PCI controller is just a thin wrapper around generic_pcie_fdt_driver.

The only issue therefore is mips, which has some drivers that indeed appear to not be compatible. Testing a MALTA64 kernel in QEMU it's no longer able to attach to pci0 as it can't allocate a bus number; mips's resource.h unconditionally defines PCI_RES_BUS whenever NEW_PCIB is defined, but not all its pcib drivers support it. From what I can see, all of ar71xx_pci, ar724x_pci, qca955x_pci, octopci, gt_pci and xlp_pci will fail PCI_RES_BUS allocations, with just mtk_pcie supporting it, hence why that was the only config with it. So I guess we just wait until we're free from mips; I could fix gt_pci so MALTA64 keeps working (which, given it's what gets used for QEMU, is about the only kernel config anyone's actually using) but that would be a waste of time.

(the device pci but currently not NEW_PCIB arm kernel configs being just ALPINE, ARMADA38X and ARMADAXP)

Now that sparc64 and mips are gone, what's the status of this?

I believe there's nothing blocking it, bar rebasing, but more scrutiny would probably be good to verify I'm not missing something when asserting that all drivers should be compatible, especially in the 32-bit Arm department

In D32954#863796, @jrtc27 wrote:

I believe there's nothing blocking it, bar rebasing, but more scrutiny would probably be good to verify I'm not missing something when asserting that all drivers should be compatible, especially in the 32-bit Arm department

Maybe @mmel or @mw could confirm that everything is ok for 32 bits arm, I don't have any board with PCI

In D32954#863891, @manu wrote:

In D32954#863796, @jrtc27 wrote:

I believe there's nothing blocking it, bar rebasing, but more scrutiny would probably be good to verify I'm not missing something when asserting that all drivers should be compatible, especially in the 32-bit Arm department

Maybe @mmel or @mw could confirm that everything is ok for 32 bits arm, I don't have any board with PCI

Also happy to just do a scream test if pre-commit testing is hard to come by for the affected configs :)

Also happy to just do a scream test if pre-commit testing is hard to come by for the affected configs :)

That sounds reasonable to me. We could always implement missing functionality, fix bugs, or even revert the commit if necessary.

Glancing over the arm parts of the change, and if it compiles, it looks like there's an excellent chance that things will just work. There weren't that many 32-bit ARM platforms with actual PCI busses that we supported.
And I have no reason to think that it won't just work on those platforms...
Call for testing might not be bad, though... It looks like mostly an unifdef run though for things that are now always defined.

I've applied this patch and it seems to work just fine with a ARMADA38X config, which didn't use the NEW_PCIB option before.
That is the system boots, but I don't have anything plugged into the pcie slot at the moment.
I'll look for a card that I can put in, and will let you know if it works.

Everything else looks fine to me aside from the missing #else.