On Wed, 2011-06-08 at 16:49 -0700, Jesse Barnes wrote: > On Thu, 09 Jun 2011 09:05:05 +1000 > Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, 2011-06-08 at 11:47 -0700, Jesse Barnes wrote: > > > > > > So basically an arch hook in place of a quirk for everything? Yeah > > > that's probably clearer, and maybe there's some code in a catch all > > > quirk that could be moved there on other arches as well. > > > > Hrm, quick vs hook ... that's orthogonal. > > > > But we don't have a quick today that is called before we start poking at > > the slot with config space, do we ? > > > > We can't do quirk until we have some sort of pci_dev around right ? > > Well I thought an early quirk might be good enough for this, since it > occurs before we go poking at BARs. But either way, an arch hook for > arch stuff is more self-documenting. Right, and early quirk wouldn't work for me as I really need to get in before we even do the config accesses to "probe" the device. Device are "isolated" by a mix of FW and HW in what we call "PE's" (Partitionable endpoing) and things need to be setup prior to access. Right now we have a boot time loop going through the device-tree doing that which introduce code duplication with hotplug, along with other nastyness, I want to basically set things up lazily right before we try to probe. This will fit better with my new backend too. I'll send a patch later when I'm closer to something working, thanks for your feedback. Cheers, Ben. -- 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
