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;