Felipe Balbi <balbi@xxxxxxxxxx> writes: > Hi, > > Robert Jarzmik <robert.jarzmik@xxxxxxx> writes: >>>> And as bonus question, why is it better to have mdelay() calls in the driver ? >>> >>> As a bugfix, it's the smallest fix possible, right? Ideally, we wouldn't >>> need either of them. Perhaps there's a bit which can be polled instead? >> Ideally yes. Do you remember if a "threaded interrupt" might use msleep() ? I >> seem to remember that they can, so won't that be another alternative ? > > yeah, unless, of course, you have a spinlock held. ;-) Ah yes, unless that :) I would have proposed to call the disconnect out of the spinlock path, but looking at the r8a66592_usb_disconnect(), with its spinlock flip-flop, I loose heart ... And even if I still think no mdelay() should be used, because of the kernel stall (and global uniprocessor stall), I won't argue anymore. After all, if you let in the mdelay(), perhaps the maintainers will agree to review their architecture and drop the locks or sleeps in interrupt context in a follow-up patch, who knows ... Cheers. -- Robert -- 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
