Oliver Neukum <oneukum@xxxxxxx> writes: > On Wednesday 10 October 2012 15:11:29 Bjørn Mork wrote: > >> 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. > > We support all valid configurations. Of course. I was not suggesting that we shouldn't fix this for the composite device. Only that we could fix it and keep existing behaviour for non-composite devices. >> 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? > > Well, the code would be more complex, not easier. Yes, and the gain is probably neglible. At least until GFP_NOIO allocations start failing. So forget about this. >> 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. > > It would be much, much easier to just unconditionally use GFP_NOIO. You are of course right. It just felt so wrong. But I can learn to live with that :-) Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
