00:52:44 jbk: As in why did we look up the dip directly that way? 00:56:38 yeah 00:59:50 (or if there was no reason) 01:03:55 I don't recall any particular reason. I would guess probably just implementation side effects. 01:04:11 ok 01:04:51 it'd probably be reasonable to and drop the use of pci_bus_res. Sorry I don't have a better answer. 01:05:00 no that's fine.. 01:06:11 It probably would be better to do that and drop the use of pci_bus_res[] thinking out loud. 01:06:41 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. 01:14:16 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) 01:15:32 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 01:16:00 (I'm trying to break things up into smaller logical chunks -- whether they get all squashed or not is TBD) 01:19:20 (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) 01:20:49 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) 03:49:27 BTW I can report success with the https://github.com/LuminousMonkey/xf86-video-illumosfb on a system built around a "12th Gen Intel(r) Core(tm) i5-1235U"