02:37:00 <rzezeski> richlowe: I'd like to see it added, but I personally have not had the time or priority for it yet.
03:32:10 <jbk> richlowe: that would be nice... i'll hopefully know more next week, but there's a pretty decent chance that I'll _will_ need PCI segment support, and quickly... even if I have to do a 'quick and dirty' and not something upstreamed, but it'd be nice if I could at least advance the state of things towards where we want to go, even if not everything goes upstream (because quick and dirty)
17:20:47 <rmustacc> jbk: In terms of where we want to go, I started drafting something a while back on that, but still needs some work: https://github.com/illumos/ipd/blob/master/ipd/0060/README.adoc
17:26:07 <rmustacc> Basically short form is add a new pci-segment property on root ports using a prd method to figure it out. Then nexus drives like npe need to look at that property on children when it's doing a bus map and translate appropriately.
17:27:09 <rmustacc> While I'm not goign to have a ton of spare time over the coming weeks, let me know how I can help here jbk. I think something simple won't be too bad as long as you don't care about userland tooling like pcieadm or some of the other stuff working 100%.
17:28:16 <rmustacc> I'll see if I can get some stuff firmed up there and get the doc into broader discussion.
19:48:54 <jbk> i actually have some bits from trying to get the HP Gen12's working (since i was still trying to figure out what was needed) that actually sets a property (I guess a good sign I also picked 'pci-segment' for it :P) on all the NPE devices... I'm guessing/hoping where we're accessing cfgspace with a dip for the dev in question, it shouldn't be too bad to just lookup the property (letting it inherit from the 
19:49:00 <jbk> ultimate parent npe)
19:49:55 <jbk> the ugly part is all the alternate ways we seem to have in x86 to access cfg space (even when it seems like we should have a good dip to use)
19:55:01 <jbk> there's the pci_{get,put}{b,w,l}_func() pointers, then there's pci_cfgacc_acc_p (which does use the former, but also at least includes a dip)
19:55:40 <jbk> then there's pci_config_{rd,wr}{8,16,32} (and the rep variants) which only sometimes have a dip
19:57:06 <jbk> not to be confused with DDI pci_config_{get,put}{8,16,32,64} functions
19:57:17 <jbk> and as far as I can tell are specific to x86
20:28:57 <richlowe> They call eachother
20:29:08 <richlowe> you can get rid of one layer (I did)
20:29:42 <richlowe> I think richlowe/arm64/pci-hacking may still exist
20:30:05 <richlowe> richlowe/arm64/pci* even, there's other cfgspace-y things in there
20:30:41 <richlowe> have any of you messed with id32?
20:31:08 <richlowe> and/or know why " * For amd64 the 32 bit id is the offset of the entry in the arena"
20:32:18 <richlowe> jbk: and https://github.com/richlowe/illumos-gate/blob/arm64-gate/doc/pci-express/pci-express.adoc
21:49:27 <richlowe> wow, I am nonplussed by id32