On Thu, May 17, 2018 at 08:20:51AM -0600, Keith Busch wrote: > > Heh. But yes, this test and the PCI "enable" interface in sysfs look > > horribly wrong. pci_disable_device/pci_enable_device aren't something we > > can just do underneath the driver. Even if injecting the lowlevel > > config space manipulations done by it might be useful and a good test > > the Linux state ones are just killing the driver. > > Yes, I'm totally fine with injecting errors into the config space, but > for goodness sakes, don't fuck with the internal kernel structures out > from under drivers using them. > > My suggestion is to use 'setpci' to disable the device if you want to > inject this scenario. That way you get the desired broken device > scenario you want to test, but struct pci_dev hasn't been altered. > > > The enable attribute appears to have been added by Arjan for the > > Xorg driver. I think if we have a driver bound to the device we > > should not allow it. > > Agreed. Alternatively possibly call the driver's reset_preparei/done > callbacks. Exactly, but as long as we can issue the reset via sysfs the test-case is still valid. -- Johannes Thumshirn Storage jthumshirn@xxxxxxx +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
