Comment 277 for bug 85488

Most problems are thought out at least once before people start curtly responding "well it's an incompatibility with XYZ and we can't do anything unless they fix XYZ and this is what we think is the best way of fixing it" -- summing things up elegantly does take some work. (Performing Google searches under site:lkml.org are always a good place to start.)

As for the "broken devices" -- that's inevitable. From what I recall, there is a mechanism within a certain proprietary OS which holds a significant market share that says to the user, "Sorry, we can't suspend this computer because device XYZ is preventing it from happening; disconnect it if you want to suspend". To me, I suspect the best way of handling the situation is not a blacklist, but rather a whitelist -- only the components are safe to suspend on should be suspended. If a driver/device does not support suspend, then don't suspend it (at the driver/module level) and tell the user that s/he must disconnect the device if they want USB_SUSPEND. (And if the module is untested, or supports hardware that both does and does not suspend properly, then make it a kernel or runtime config whether that driver/module should use USB_SUSPEND. And add a way of configuring whether devices should be suspended if they're unknown...) Of course, depending on how USB_SUSPEND works, that might mean USB_SUSPEND would be useless if so much as one device is incompatible... but that might have to be a trade-off for this sort of thing.

That said, blacklists tend to be more forward-thinking, IMO... (don't treat a device special unless we have to). For something like USB_SUSPEND which saves power and is useful but isn't crucial to a device's functioning, I suspect it would be better to use a whitelist at the expense of USB_SUSPEND being applied to more devices. Assuming that is possible, which I am not sure about.

Just my two cents.