On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote: > On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote: >>> I assume you're talking about the one added by cf3e1feba7f9 ("PCI: >>> Workaround missing pci_set_master in pci drivers"), but as far as I >>> can tell, it only calls pci_set_master() for *bridge* devices. What >>> am I missing? Is pci_set_master() being called for your endpoint? >>> What path is that? >> >> Yes, it is being called during execution of the _probe() function in my driver, >> as evidenced by the annoying (and wrong) message it produces. >> >> Next time I've got the hardware at hand, I'll put a "dump_stack()" into there >> to see the exact calling path. > > Note that one of the reason we want to do it early on bridges is that without it, > we may also not get the PCIe error messages. Sure, for bridges. I'll get a stack trace later today, but what I suspect is happening is that this multi-function card is being treated by the PCI layers as a "bridge" for purposes of the multiple virtual functions it implements. We will probably need to distinguish this kind of device from real bridges here. -- Mark Lord Real-Time Remedies Inc. mlord@xxxxxxxxx -- 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