[PATCH 1/2] usb drivers: use BUG_ON() instead of if () BUG

2015-05-19 Thread Mauro Carvalho Chehab
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 mche...@osg.samsung.com

diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c 
b/drivers/media/usb/cx231xx/cx231xx-417.c
index 855a708387c6..47a98a2014a5 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1249,8 +1249,7 @@ static void free_buffer(struct videobuf_queue *vq, struct 
cx231xx_buffer *buf)
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) {
diff --git a/drivers/media/usb/cx231xx/cx231xx-vbi.c 
b/drivers/media/usb/cx231xx/cx231xx-vbi.c
index 80261ac40208..a08014d20a5c 100644
--- a/drivers/media/usb/cx231xx/cx231xx-vbi.c
+++ b/drivers/media/usb/cx231xx/cx231xx-vbi.c
@@ -192,8 +192,7 @@ static void free_buffer(struct videobuf_queue *vq, struct 
cx231xx_buffer *buf)
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,
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c 
b/drivers/media/usb/cx231xx/cx231xx-video.c
index af44f2d1c0a1..c6ff8968286a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -749,8 +749,7 @@ static void free_buffer(struct videobuf_queue *vq, struct 
cx231xx_buffer *buf)
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,
diff --git a/drivers/media/usb/tm6000/tm6000-video.c 
b/drivers/media/usb/tm6000/tm6000-video.c
index 77ce9efe1f24..26b6ae8d04da 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -714,8 +714,7 @@ static void free_buffer(struct videobuf_queue *vq, struct 
tm6000_buffer *buf)
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,
diff --git a/drivers/media/usb/zr364xx/zr364xx.c 
b/drivers/media/usb/zr364xx/zr364xx.c
index ca850316d379..7433ba5c4bad 100644
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -377,8 +377,7 @@ static void free_buffer(struct videobuf_queue *vq, struct 
zr364xx_buffer *buf)
 {
_DBG(%s\n, __func__);
 
-   if (in_interrupt())
-   BUG();
+   BUG_ON(in_interrupt());
 
videobuf_vmalloc_free(buf-vb);
buf-vb.state = VIDEOBUF_NEEDS_INIT;
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] usb drivers: use BUG_ON() instead of if () BUG

2015-05-19 Thread Lad, Prabhakar
On Tue, May 19, 2015 at 12:00 PM, Mauro Carvalho Chehab
mche...@osg.samsung.com wrote:
 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 mche...@osg.samsung.com

Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com

Cheers,
--Prabhakar Lad
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html