Generally looks okay. However, you should keep the check for an unsupported number of ranges but change it to ensure that the device tree doesn't include more than PSYCHO_NRANGE, i. e. 4, ranges or alternatively additionally limit the loop to PSYCHO_NRANGE. Otherwise, a device tree having more than 4 ranges would now cause an out-of-bounds array access.

Any update on this patch at all?

In D2791#54023, @marius wrote:

Generally looks okay. However, you should keep the check for an unsupported number of ranges but change it to ensure that the device tree doesn't include more than PSYCHO_NRANGE, i. e. 4, ranges or alternatively additionally limit the loop to PSYCHO_NRANGE. Otherwise, a device tree having more than 4 ranges would now cause an out-of-bounds array access.

The range[] array is dynamically allocated, so there shouldn't be an out-of-range access by the for loop, yes? The pci_bh[] array is only indexed by the result of OFW_PCI_RANGE_CS() and that only returns values 0 through 3.

Hmm, looks like the fire and schizo drivers have the same code. It seems like STX_NRANGE and friends should really be replaced by an OFW_PCI_NRANGE constant since those arrays are indexed by OFW_PCI_RANGE_CS values, not the indices of the raw ranges property.

Thanks for the patch, it does fix the psycho panic in qemu for me as well (the kernel still hangs at some later stage); tested against fresh -CURRENT sources.