In commit 8aff8ba95155df, most of the manipulations to vbuf inside
copy_streams were gated on if !dev->radio, but one place that touches
vbuf lays outside those gates -- a memcpy of vbuf isn't NULL. If we
initialize vbuf to NULL, that memcpy will never happen in the case where
we do have dev->radio, and otherwise, in the !dev->radio case, the code
behaves exactly like it did prior to 8aff8ba95155df.

While we're at it, also fix an incorrectly indented closing brace for
one of the sections touching vbuf that is conditional on !dev->radio.

v2: add a detailed commit log and fix that brace

CC: Dan Carpenter <erro...@gmail.com>
CC: Dmitri Belimov <d.beli...@gmail.com>
CC: de...@driverdev.osuosl.org
Signed-off-by: Jarod Wilson <ja...@redhat.com>
---
 drivers/staging/tm6000/tm6000-video.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tm6000/tm6000-video.c 
b/drivers/staging/tm6000/tm6000-video.c
index c80a316..8b971a0 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -228,7 +228,7 @@ static int copy_streams(u8 *data, unsigned long len,
        unsigned long header = 0;
        int rc = 0;
        unsigned int cmd, cpysize, pktsize, size, field, block, line, pos = 0;
-       struct tm6000_buffer *vbuf;
+       struct tm6000_buffer *vbuf = NULL;
        char *voutp = NULL;
        unsigned int linewidth;
 
@@ -318,7 +318,7 @@ static int copy_streams(u8 *data, unsigned long len,
                                        if (pos + size > vbuf->vb.size)
                                                cmd = TM6000_URB_MSG_ERR;
                                        dev->isoc_ctl.vfield = field;
-                       }
+                               }
                                break;
                        case TM6000_URB_MSG_VBI:
                                break;
-- 
1.7.1

--
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

Reply via email to