On Tuesday, November 11, 2008 11:58 am Benjamin Herrenschmidt wrote: > On Tue, 2008-11-11 at 09:10 -0800, Jesse Barnes wrote: > > On Monday, November 10, 2008 10:04 pm Benjamin Herrenschmidt wrote: > > > Hi Jesse ! > > > > > > Any reason why we don't create the legacy_io/mem files for child > > > busses ? > > > > > > The fact that they only exist for PHBs makes it tricky for userspace > > > programs to find them > > > > > > Since they only appear in /sys/class/pci_bus/* which has no hierarchy > > > information, a user space program like in my case that gets passed a > > > sysfs path to a device, would have to walk back up the chain to find > > > out the phb in order to then find it in there. > > > > Yeah, in that case it's a bit more of a pain to find. Originally though > > we figured that the legacy spaces were per-domain or host bridge > > resources, so it didn't make sense to propagate them down to child > > busses. If that's not the case for your platform it probably makes sense > > to let them trickle down. > > They are per domain. It's just that it makes it more painful for > userspace to find them if they aren't everywhere. Especially on PCIe > where there's generally a P2P bridge at the root of everything. > > > I'd have to go make sure the code does the right thing for child buses on > > ia64... /me checks. I think base ia64 will be ok, but whether sn works > > would depend on how the PROM fills in the legacy_mem address (i.e. it > > should work but would need testing). > > Or you can internally make it walk up to the PHB ... Yeah, I don't think there will be any serious problems. May as well go ahead and add them on a per-bus basis, but be sure to update the documentation so people don't get confused and think that more than one space per domain might be available. Thanks, Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
