Was just refreshing this patch now that some of the other stuff it needs has started to land. I'll be pushing it to a mrst branch in my PCI tree soon for testing & more review. On Thu, 11 Jun 2009 14:59:45 -0700 Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > > + * Here we assume that type 1 and MCFG based access has already > > > been set up, > > > + * such that raw_pci_ops is type 1 and raw_pci_ext_ops is MCFG. > > > > How about using pci_direct_conf1 explicitly? We can make pci_mmcfg > > non-static too. > > Hm, I'll look at that. I went back and forth on a couple of > possibilities here. I think I can do this, it would make things clearer. > > Do we need to find this before we can call > > pci_find_ext_capability()? Can we create > > pci_bus_find_ext_capability() analagous to > > pci_bus_find_capability()? I hate to see this kind of > > functionality hidden in an arch file somewhere. > > Agreed, I'll pull it out into generic code (as you can see by the > comment it's something I should have done already). Started looking at doing this, and remembered why I needed the funky code. At one point I was using the fixed bar check on the read side, so if I used generic code to look for the cap I'd end up with infinite recursion: pci_read->fixed_bar_cap->pci_read->... However I don't need that anymore, so it should be safe to use a generic routine here (as long as the cap walking code never does a write! :) That said I think I would need a pci_bus variant, since I'll be using it from pci_write... I'm addressing the rest of the comments now, will post a new patch shortly (though still missing a few of the generic bits that are still being pushed, like SFI and platform feature bits). -- Jesse Barnes, Intel Open Source Technology Center -- 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
