[PATCH] sq905c: remove unused variable

[PATCH] sq905c: remove unused variable

[Douglas Schilling Landgraf]

[-- Attachment #1: Type: text/plain, Size: 108 bytes --]

Removed unused variable.

Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>

Thanks,
Douglas

[-- Attachment #2: patch-sq905c.diff --]
[-- Type: application/octet-stream, Size: 395 bytes --]

diff -r 2a50a0a1c951 linux/drivers/media/video/gspca/sq905c.c
--- a/linux/drivers/media/video/gspca/sq905c.c	Sat Jan 23 00:14:32 2010 -0200
+++ b/linux/drivers/media/video/gspca/sq905c.c	Sat Jan 23 21:40:42 2010 -0200
@@ -204,7 +204,7 @@
 {
 	struct cam *cam = &gspca_dev->cam;
 	struct sd *dev = (struct sd *) gspca_dev;
-	int i, ret;
+	int ret;
 
 	PDEBUG(D_PROBE,
 		"SQ9050 camera detected"

Re: [PATCH] sq905c: remove unused variable

[Theodore Kilgore]

On Sat, 23 Jan 2010, Douglas Schilling Landgraf wrote:

> Removed unused variable.
>
> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
>
> Thanks,
> Douglas
>

Douglas,

Thanks for your sharp eyes.

However, I _think_ that this particular problem may have already been 
fixed, recently if not some time before. In particular, recent changes 
have been done in the version of sq905c.c which lives in the gspca tree of 
Hans de Goede. I am working off his tree these days because we have been 
doing a number of things together, and thus the changes there to sq905c.c 
have been done by a patch from here.

These changes were done in order to add a couple of new cameras and to 
change the way to decide whether the camera is a VGA or a CIF camera. The 
determination of this by USB Product number does not always work, and one 
needs to read an ID string from the camera in order to learn it better. 
Who bought the camera which has the "wrong" resolution setting associated 
with its USB Product number? Hans de Goede.

It appears to me that this patch is not relevant to that most recent 
version of sq905c.c. At least, it does not fit here, which is where it 
appears it is supposed to fit:

/* This function is called at probe time just before sd_init */
static int sd_config(struct gspca_dev *gspca_dev,
 		const struct usb_device_id *id)
{
 	struct cam *cam = &gspca_dev->cam;
 	struct sd *dev = (struct sd *) gspca_dev;
 	int ret;

 	PDEBUG(D_PROBE,
 		"SQ9050 camera detected"


If everyone else is agreeable, I would propose that the recent changes to 
sq905c.c should simply be pulled, and that is the best solution to the 
problem.

Hans, can you confirm all of this?


Theodore Kilgore

Re: [PATCH] sq905c: remove unused variable

[Jean-Francois Moine]

On Sat, 23 Jan 2010 19:44:06 -0600 (CST)
Theodore Kilgore <kilgota@banach.math.auburn.edu> wrote:

> If everyone else is agreeable, I would propose that the recent
> changes to sq905c.c should simply be pulled, and that is the best
> solution to the problem.

A pull request for this change has been sent last sunday.

Cheers.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [PATCH] sq905c: remove unused variable and other topics

[Theodore Kilgore]

On Sun, 24 Jan 2010, Jean-Francois Moine wrote:

> On Sat, 23 Jan 2010 19:44:06 -0600 (CST)
> Theodore Kilgore <kilgota@banach.math.auburn.edu> wrote:
>
>> If everyone else is agreeable, I would propose that the recent
>> changes to sq905c.c should simply be pulled, and that is the best
>> solution to the problem.
>
> A pull request for this change has been sent last sunday.

Jean-Francois,

Thanks.

I would also like to address three other items.

1. For a long time I was not getting the mail from this list. I could 
not figure out what was the matter, but I finally remember what happened:

I went on a two week vacation last summer, and I unsubscribed before I 
left home, since I did not want to deal with what seemed like several 
hundred messages a day piling up unread in my inbox. Then when I got back 
I was too busy trying to catch up with work to remember to resubscribe. 
Fixed, now.


2. I hope that when you got the sq905c changes that you also pulled the 
changes for mr97310a.c. Several things have been done there recently.

First, there was a patch to the initialization for one of the types of 
supported cameras. Without that patch the camera will work only on a host 
machine with OHCI USB support and will fail to stream when hooked to a 
host machine with a UHCI controller. There was a desperate, last minute 
attempt to get this patch into 2.6.32, the urgency of which apparently 
failed to convince the higher-ups and it did not get in. The only excuse 
for the bad timing is the obvious one, that who could imagine that such a 
problem could occur until actually confronted with it? It is just too 
weird. I do not know the current status of this patch.

Second, other cleanups have been done to mr97310a.c

Third, another camera with yet another init sequence and control 
capabilities has been discovered, and it is added to mr97310a.c

I would say that the most recent version of the mr97310a driver is the 
best and most bug-free of the versions, and I hope it gets used.

3. The sn9c2028 driver. It runs the three sn9c2028 cameras that I have on 
hand and does so pretty well.

I would characterize the driver as unfinished, though. For, there are at 
least two cameras supported there which I do not and never did personally 
own, and therefore I cannot test them. I do have init sequences which are 
based upon snoops previously done, and I put those in the driver. 
Unfortunately, I have been unable to get anyone else to test those two 
cameras, either. Apparently, the only way to get them tested is to send 
the driver mainstream. After that, perhaps I will get reports whether they 
work, or not!

The two cameras in question which are untested or are incompletely tested 
are (quoting from sn9c2028.c)

         {USB_DEVICE(0x0458, 0x7005)}, /* Genius Smart 300, version 2 */
         /* The Genius Smart is untested. I can't find an owner ! */

and

         {USB_DEVICE(0x0c45, 0x8008)}, /* Mini-Shotz ms-350 */

where the owner tells me that the code I sent him works, but he can not do 
more testing right now because he is too busy (wife is having first 
child). The Mini-Shotz has obvious redundancies and bactrackings in the 
init sequence which is used in the OEM driver. I would very much like to 
be able to clean out all the crud which is in the OEM init sequence, but I 
have no way to know exactly what is needed, without testing.

Thus, if anyone who reads this has either of the above sn9c2028 cameras or 
any other one which is not currently supported at all, please contact me. 
There is a lot of unfinished business with the sn9c2028 driver. I would 
very much like for it to get done. But said work depends upon finding 
owners and testers.


Theodore Kilgore