[PATCH] staging: easycap: fix build failure

[PATCH] staging: easycap: fix build failure

[Jiri Kosina]

This fixes:

	drivers/staging/easycap/easycap_main.c:4251:3: error: implicit declaration of function 'lock_kernel'
	drivers/staging/easycap/easycap_main.c:4254:3: error: implicit declaration of function 'unlock_kernel'

We need to include smp_lock.h in order to have BKL primitives (the driver
already correctly depends on BKL).

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---

Now, I really believe that this driver is completely hopeless and the only 
option is complete from-scratch rewrite. I have been looking into it for 
approximately ~30 seconds (solely to fix this build failure), and I really 
don't know what to say.

- what kind of super-crazy indentation does it have? Seems like it lost 
  first level of indentation somewhere. Completely unreadable.
- understanding what field2frame() does is probably completely hopeless 
  effort
- copying textual representation of errno into some buffer (just grep of 
  errbuf) is crazy.  Fortunately, the strings are copied there and never 
  used ... :P
- all the SAY(), JOT() macros ... what's the point?
- easysnd_testtone() seems to implement it's own kind of 
  endianity-sensitive memcpy(). Why does the for(...) cycle depend on
  PAGE_SIZE? How much memory will it corrupt on architectures with
  larger page size than what the author had in mind?

... and then I stopped reading.

 drivers/staging/easycap/easycap.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/easycap/easycap.h b/drivers/staging/easycap/easycap.h
index 25961c2..caa9298 100644
--- a/drivers/staging/easycap/easycap.h
+++ b/drivers/staging/easycap/easycap.h
@@ -88,6 +88,7 @@
 #include <linux/fs.h>
 #include <linux/delay.h>
 #include <linux/types.h>
+#include <linux/smp_lock.h>
 
 /*vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv*/
 #if defined(EASYCAP_IS_VIDEODEV_CLIENT)
-- 
1.7.1

Re: [PATCH] staging: easycap: fix build failure

[R.M. Thomas]

Jiri Kosina wrote:
> Now, I really believe that this driver is completely hopeless and the only 
> option is complete from-scratch rewrite. I have been looking into it for 
> approximately ~30 seconds (solely to fix this build failure), and I really 
> don't know what to say.

You are quite right of course.  This driver does indeed require a complete
re-write.  The non-standard formatting and (now) redundant debugging macros
are actually the least troublesome issues.  More significant is the need to
replace most of the routines by existing functions from the V4L subsystem.
Unfortunately I shall be unable to undertake this essential work myself in
the foreseeable future owing to other commitments.  Probably the simplest
solution would be to drop the driver from staging.

Even in its present untidy state the driver does work reasonably well on x86
and x86-64, so something could possibly be salvaged from it.

Mike