http://kerneltrap.org/taxonomy/term/923/0 en-local http://kerneltrap.org/Linux/Whitelists_and_Blacklists <div class="taxonomy-images"><a href="/news/linux" class="taxonomy-image-links"><img src="http://kerneltrap.org/files/category_pictures/K-Linux.gif" alt="Linux news" title="Linux news" width="75" height="75" /></a></div><!-- google_ad_section_start --><p>"<i>It turns out that USB devices suck when it comes to powermanagement issues :(</i>" <a href="http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/259148">lamented Greg KH</a> in posting some patches to handle USB autosuspend problems. He noted that the patches were intended for inclusion in the upcoming 2.6.23 kernel, "<i>a number of patches have been submitted near the end of this kernel release cycle that add new device ids to the quirk table in the kernel to disable autosuspend for specific devices. However, a number of developers are very worried that even with the testing that has been done, once 2.6.23 is released, we are going to get a whole raft of angry users when their devices break in nasty ways.</i>" He proved an example, "<i>it seems that almost 2/3 of all USB printers just can not handle autosuspend. And there's a _lot_ of USB printers out there...</i>"</p> <p><a href="http://kerneltrap.org/mailarchive/linux-kernel/2007/9/13/259275">Later in the discussion</a>, Linux creator Linus Torvalds commented, "<i>in general, I think the USB blacklist/whitelists are generally a sign of some deeper bug.</i>" He continued on to point out a number of quirks in the USB layer that need to be addressed and added:</p> <blockquote><p>"We used to have a lot of those things due to simply incorrect SCSI probing, causing devices to lock up because Linux probed them with bad or unexpected modepages etc. I suspect we still hav