Oliver Neukum <[email protected]> writes: > For mice with card readers the HID driver can deadlock > as its post_reset() method allocates memory. GFP_NOIO > must be used in a block layer error handler, which > usbhid can be indirectly part of.
I am wondering a bit where this will eventually end. Given enough time, I assume we will see all USB interface drivers attached to some composite device with a usb-storage function. Although it probably won't hurt that much, it feels somewhat wrong to put unnecessary restrictions into all existing interface drivers just because there is some device which in theory could cause the driver to lockup. After all, I am pretty sure that more than 99% of the devices using the mouse driver won't have a card reader. Instead of assuming the worst, wouldn't it make more sense to add some real knowledge about the composite device restrictions at the device level, and then use this knowledge in the interface drivers? Maybe let drivers like usb-storage register a restriction and create a pm_or_reset_gfp(struct usb_device *) function returning the appropriate flag for the other interface drivers? This function could the return GFP_KERNEL to the mouse driver for the common single HID function device, and GFP_NOIO for the composite mouse+storage device. Bjørn -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
