On Wed, 2 Jun 2010, Rafael J. Wysocki wrote: > > > Do PCI bus type callbacks need to be reworked to work correctly with unbound > > > devices? > > > > They do; I neglected to take care of them when first writing this > > patch. After everything is working I'll submit it for real. For now, > > the point was to find out whether this is going in the right direction. > > I don't have a fundamental problem with it. As long as all things can be made > work along these lines, it's fine by me. Arggh! I just tried out a revised patch. It seems to work perfectly, except for one thing. When I unbound ehci-hcd from one of the USB controllers, which should have caused the controller to be runtime-suspended, this is what showed up in the log: [ 295.651545] pci 0000:00:1d.7: PME# enabled [ 295.664044] pci 0000:00:1d.7: Refused to change power state, currently in D0 Which seems to mean that the controller didn't want to go into D3hot! Presumably this is because it was unconfigured when the driver was unbound. That's the only explanation I can think of; the controller had no objection about going into D3hot when it was bound to the driver. Assuming other PCI devices will have similar behavior, I have to agree that there's no point trying to put driverless devices into low-power states. One more thing: When looking at the r8169 and e1000e drivers, I noticed that you used the same test (pci_dev_run_wake -- not the greatest name in the world, BTW) in both the probe and remove routines. That's not the right thing to do if the runtime-wakeup setting could get changed inbetween. (I realize that currently there is no way to change the setting, but in the future there might be.) Do you want to make an explicit assumption that the runtime wakeup settings are fixed, not subject to change? If so, then why not compute the setting just once, when the device is registered, and store it in the pci_device structure? Or even in the struct device? Alan Stern -- 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
