[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] testing of Xen PCIbackend support for slot and bus reset
Use the 'do_flr' SysFS instead of the 'reset'. Once an PCI device Got a bit confused by the conditional check for the presence of reset file in pcistub_try_create_reset_file(). You are absolutely correct in that these devices are owned by pciback and not another driver. Can an alternate reset file (with another reset function) be created at an earlier stage or is this a guard to prevent the reset file (calling pcistub_reset_store()) from being created multiple times? Still a bit confused. I may be missing something, but the sysfs file name used for pcistub_reset_pci_dev() seems to be "reset". The function shall do FLR and, if possible, D3/bus/slot reset as fallback but only if it has no side effects for other functions on the device (equivalent to a real FLR). Shouldn't this function be registered as en emulated "do_flr" file instead of "reset"? And the 'reset' does not do a bus-reset (whcih is what you need for  The reset function in this branch looks similar to the one in devel/xen-pciback.slot_and_bus.v0. I have tested the latter and I can verify that it works well. I had to do some additional changes to avoid infinite wait after a couple of reboots but the reset function worked well. /Martin Â
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |