Looks good to me. A better, longer-term, change would be to replace this list entirely with a dynamically allocated linked list or something. It isn't used in early boot (before malloc), or from assembly, or from anywhere performance-critical, so there's really no reason to keep it like this.

In D12421#258230, @wma wrote:

Oh, I indeed forgot to add -U9999 to the format-patch, sorry.

As for the installation of fbsd on P8, I have a plan to investigate what can be done to make the petitboot running the freebsd kernel or loader netively.
I see two solutions - just ideas, I didn't check their feasibility yet:

1. Modify kexec+petitboot to understand freebsd kernel. Right now it finds that the ELF is relocatable and refuses to go further. Most likely it would require porting loader.kboot into petitboot.

OK. That's a pain to deal with. However, I'm not sure how we would make, say, ppc64 install media that include a usable loader.kboot in this configuration along with other cis-endian loaders. Maybe the answer is that we don't, that we use direct kexec() of our kernel (from the powernv branch) on install media, and leave a usable loader.kboot as an optional feature that people have to set up by hand?

How does this interact with the libstand build, which also needs to be little-endian? Is there a way to make the build system create both loader.kbootbe and loader.kbootle (or the like) by default, rather than relying on a custom build flag?

Yes, I think that's fine. Sorry for the delay. Insofar as we keep this API existing, it should work properly and this patch helps achieve that. Please be careful using it, and, if you have some spare cycles, it would be worth thinking about how to make it more reliable still.

Looks good. We may need to think some more about the implementation of this function if we need to bump it again, but I cannot think of a better approach offhand.

Aside from my general objections to the whole concept of "fixups", this looks good.

Is this expected to actually work with FDT? I had thought the limitation was just that there is no free space in our FDTs, and we don't reallocate them, so that -- in general -- you can't add properties. You certainly can't on my hardware.

Looks good to me.

Related to Allan's point, nothing in the hardening menu should ever be turned on by default. If we want to change the system defaults, we should change the system defaults. Having the defaults be different depending on whether the installer is used to set up the system is a super bad idea and one I would object to vigorously.

In D7571#161544, @meloun-miracle-cz wrote:

it's able to enumerate devices which are present in DTS under the PCI-controller node, which are not PCI devices

I don't think that this is right. The nodes under PCI-controller node describes configuration for individual ports of PCIe root complex, these are part of PCIe-controller configuration.
These are not a independent devices at all so instantiation new newbus devices for them looks like pure nonsense.

In D7571#161529, @wma wrote:

In general, pci_generic contains one feature which ofw_pci lacks: it's able to enumerate devices which are present in DTS under the PCI-controller node, which are not PCI devices. I know this is a mess and does not comply with standard nor logic, but some arm64-vendors are using this type of DTSes and by now it is hard to convince them to fix DTS once it's already been put into production.

This looks good to me.

Looks Ok to me. Any idea why things were set up this way to begin with?

Looks good. Thanks!

Looks good. I had two remaining comments, neither of which should block merging:

1. I think this would be better to inherit from ofwpci than pci_generic, since the code just works around all the things pci_generic adds to ofwpci.
2. The DTS bindings being used don't match the vendor ones. Barring some compelling reason to diverge, I think we should use the vendor's device trees.

Actually update the diff, since I still forgot that file last time.

Fix missing file.

Is there any reason these bindings diverge from the ones from the vendor? http://lxr.free-electrons.com/source/arch/arm/boot/dts/alpine.dtsi

Looks good to me.

Fix unused variable and make patch relative to src/ rather than src/sys.

Note: This partially implements the changes in D918.

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