jbk: As in why did we look up the dip directly that way?

yeah

(or if there was no reason)

I don't recall any particular reason. I would guess probably just implementation side effects.

ok

it'd probably be reasonable to and drop the use of pci_bus_res. Sorry I don't have a better answer.

no that's fine..

It probably would be better to do that and drop the use of pci_bus_res[] thinking out loud.

I expect I was thinking I wanted to just separate the two so one could change that all out without impacting the logic per se.

yeah, i'd like to get there... but for the stuff i'm doing, i'm trying to just do the same probing/allocation logic we do today, just repeated for each segment (more or less)

but having the code use a pointer to the struct pci_bus_resource instead of accessing the array directly everywhere would hopefully make it easier to repeat the logic for each segment

(I'm trying to break things up into smaller logical chunks -- whether they get all squashed or not is TBD)

(the other big bit is to use pci_cfgacc_xxx() and pass around the rc dip (or i guess root bridge if it's not pcie) as needed instead of directly calling the pci_{get,set}{b,w,l}() functions everywhere (at least in pci_boot.c and a few other places)

that does require a _small_ change in pci_boot.c, but not one that actually changes the actual probe logic (we need to create the bus 0 dip in the caller instead of in the callee so we can pass it as a parameter)

BTW I can report success with the github.com/LuminousMonkey/xf86-video-illumosfb on a system built around a "12th Gen Intel(r) Core(tm) i5-1235U"