W dniu 22.03.2022 o 12:38, Arthur Heymans pisze:
> sidenote: it also looks like the hardware really does not like to have
> PCI bridges on a IIO stack set a subordinate
> value larger than the IIO stack 'MaxBus' (basically a stack-level
> subordinate bus?). So scanning PCI busses needs some care.
> See https://review.coreboot.org/c/coreboot/+/59395

Each stack can have preassigned PCI bus range. window from busbase (pci
bus no of first root bus on stack) to IIO stack 'MaxBus' inclusive. If
MaxBus<busbase - no range assigned.

So you can logically (and with big simplification) imagine this as there
exists preconfigured 'virtual bridge' between CPU and stack PCI root
buses with secondary set to busbase and subordinate set to 'MaxBus'
(same for io window/mem below 4G window/mem above 4G - one of each type
per each stack)

There can also exists stacks marked as disabled or reserved with or
without defined pci bus ranges. PCI bus no defined in disabled or
reserved stacks should not be used/accessed. Access can cause
hang/lookup or very long delays. So only bus ranges defined in "enabled"
stacks should be used.

So it can be handled as you proposed in CB:59395 or we can define weak
function e.g. get_max_subordinate(int current) which return 0xff by
default and can be overriden in soc code to return real allowed max
subordinate no.

int __weak get_max_subordinate(int current) { return 0xff;};

and in src/device/pci_device.c

subordinate = get_max_subordinate(primary); // instead of subordinate =
0xff; /* MAX PCI_BUS number here */

Mariusz

_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org