>>> On 13.12.13 at 17:09, Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote: > When the toolstack wants us to drop or add an PCI device it > changes the XenBus state to Configuring - and as result of that > we find out which devices we should still be exporting out and > which ones not. For the ones we don't need anymore we need to > do an PCI reset so that it is ready for the next guest. > > We are already doing it - but it was not clear _how_ > it was done. This should make it more obvious. > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >... > --- a/drivers/xen/xen-pciback/pci_stub.c > +++ b/drivers/xen/xen-pciback/pci_stub.c > @@ -267,18 +267,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev) > /* Cleanup our device > * (so it's ready for the next domain) > */ > + pcistub_reset_pci_dev(dev); > > - /* This is OK - we are running from workqueue context > - * and want to inhibit the user from fiddling with 'reset' > - */ > - pci_reset_function(dev); > - pci_restore_state(dev); > - > - /* This disables the device. */ > - xen_pcibk_reset_device(dev); > - > - /* And cleanup up our emulated fields. */ > - xen_pcibk_config_reset_dev(dev); > xen_pcibk_config_free_dyn_fields(dev); > > xen_unregister_device_domain_owner(dev);
Does this really belong here? It's neither covered by the description, nor can I see where pcistub_reset_pci_dev() would be defined (i.e. afaict this ought to yield a build or load time error). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
