Some USB drivers have a logic at the VB buffer handling like:
	if (in_interrupt())
		BUG();
Use, instead:
	BUG_ON(in_interrupt());
Btw, this logic looks weird on my eyes. We should convert them
to use VB2, in order to avoid those crappy things.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
        struct cx231xx *dev = fh->dev;
        unsigned long flags = 0;
 
-       if (in_interrupt())
-               BUG();
+       BUG_ON(in_interrupt());
 
        spin_lock_irqsave(&dev->video_mode.slock, flags);
        if (dev->USE_ISO) {
 
        struct cx231xx_fh *fh = vq->priv_data;
        struct cx231xx *dev = fh->dev;
        unsigned long flags = 0;
-       if (in_interrupt())
-               BUG();
+       BUG_ON(in_interrupt());
 
        /* We used to wait for the buffer to finish here, but this didn't work
           because, as we were keeping the state as VIDEOBUF_QUEUED,
 
        struct cx231xx *dev = fh->dev;
        unsigned long flags = 0;
 
-       if (in_interrupt())
-               BUG();
+       BUG_ON(in_interrupt());
 
        /* We used to wait for the buffer to finish here, but this didn't work
           because, as we were keeping the state as VIDEOBUF_QUEUED,
 
        struct tm6000_core   *dev = fh->dev;
        unsigned long flags;
 
-       if (in_interrupt())
-               BUG();
+       BUG_ON(in_interrupt());
 
        /* We used to wait for the buffer to finish here, but this didn't work
           because, as we were keeping the state as VIDEOBUF_QUEUED,
 
 {
        _DBG("%s\n", __func__);
 
-       if (in_interrupt())
-               BUG();
+       BUG_ON(in_interrupt());
 
        videobuf_vmalloc_free(&buf->vb);
        buf->vb.state = VIDEOBUF_NEEDS_INIT;