Message ID | 1238170102.3791.8.camel@tux.localhost (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-path: <linux-media-owner@vger.kernel.org> Envelope-to: mchehab@infradead.org Delivery-date: Fri, 27 Mar 2009 16:07:39 +0000 Received: from vger.kernel.org ([209.132.176.167]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1LnEao-0005Qw-Os; Fri, 27 Mar 2009 16:07:39 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753161AbZC0QHH (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Fri, 27 Mar 2009 12:07:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754927AbZC0QHG (ORCPT <rfc822;linux-media-outgoing>); Fri, 27 Mar 2009 12:07:06 -0400 Received: from mail-fx0-f158.google.com ([209.85.220.158]:35516 "EHLO mail-fx0-f158.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753161AbZC0QHF (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 27 Mar 2009 12:07:05 -0400 Received: by fxm2 with SMTP id 2so1090902fxm.37 for <linux-media@vger.kernel.org>; Fri, 27 Mar 2009 09:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=pglYxfTugaYkvQtlvH4P9J+1nx6PYOkqIMYny7iuxA0=; b=tQl0EHRvXoCVEC8MH464mK0hAmlpv9I2EhvCrPZrX32OMewqrrM4kwpTMbwZshgJmH NXmQbJ8904g2WgGVJlsJIVz60EmBu9FZCE38E8PYX/37uBAtT2GCblxNg9YDBBukhIjm MHAV/mmHX3qvrqlncntEFHDHUdWzTItMfK0Xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=Riew13rRx74OBSGIq9ed1WrnIK2rPIwLOsMdqki2cCre73cfr3owfHwhuxhUICBH/J IjvBU4fmmZaianWZlEj/1z5W7xcYOc+iiBU9irFpAtixqPrwbbkFVzWJSTpxP7tD1MFt q3c3SQl3PxYzWW4uuNGe+5VGZR4ZJufthz0dw= Received: by 10.103.8.17 with SMTP id l17mr506132mui.125.1238170022572; Fri, 27 Mar 2009 09:07:02 -0700 (PDT) Received: from ?192.168.56.42? (radio.mipt.ru [194.85.80.56]) by mx.google.com with ESMTPS id i5sm3512159mue.43.2009.03.27.09.07.01 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 09:07:02 -0700 (PDT) Subject: [patch review] gspca - mr97310a: return error instead of -1 in sd_mod_init From: Alexey Klimov <klimov.linux@gmail.com> To: Jean-Francois Moine <moinejf@free.fr> Cc: linux-media@vger.kernel.org Content-Type: text/plain Date: Fri, 27 Mar 2009 19:08:22 +0300 Message-Id: <1238170102.3791.8.camel@tux.localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org |
Commit Message
Alexey Klimov
March 27, 2009, 4:08 p.m. UTC
Hello, Jean-Francois
What do you think about such small cleanup ?
---
Patch reformats sd_mod_init in the way to make it return error code from
usb_register instead of -1.
Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
--
Comments
On Fri, 27 Mar 2009 19:08:22 +0300 Alexey Klimov <klimov.linux@gmail.com> wrote: > Hello, Jean-Francois > > What do you think about such small cleanup ? > > --- > Patch reformats sd_mod_init in the way to make it return error code > from usb_register instead of -1. > > Signed-off-by: Alexey Klimov <klimov.linux@gmail.com> [snip] Applied. Thanks.
I notice that sq905.c and sq905c.c have now been added to the gspca tree. But now a question about the documentation. None of that has been addressed, as yet, neither for the sq905 nor for the sq905c cameras. The code has been added to the tree, but the accompanying documentation is, as yet, missing. I would be glad to provide it, but it seems to me that a policy question comes up, about just what to add. There are lots of cameras. Here is the problem: The sq905 module supports, as far as I know, the entire list of cameras which are supported by libgphoto2/camlibs/sq905, and probably more which I did not list there because I got tired of adding yet another camera when, in fact, functionally they were all pretty much equivalent (My bad. I know that I missed a few of them, but I was more inexperienced back then). In any event, the support for 24 cameras is explicitly listed there. The sq905c module supports, as far as I know, the entire list of cameras which are supported by libgphoto2/camlibs/digigr8. The support for 16 cameras (or 17, if the line in libgphoto2/camlibs/digigr8/library.c "Sakar 28290 and 28292 Digital Concepts Styleshot" which refers to two cameras differing only in the color of the case is counted as referring to two cameras). Thus, if the documentation would be provided in linux/Documentation/video4linux/gspca.txt it would amount to a total of 41 new entries, for these two new modules alone. Should all 41 of them be added? I would think that they all ought to be listed somewhere, but should the somewhere be there, or somewhere else? That is the question. One possibility might be to refer the curious reader to the existing list in the relevant file in libgphoto2, for example, since these are all dual-mode cameras. If that were done, then it would be only needed to put the USB Vendor:Product number into the gspca.txt file, along with a pointer to the full information. Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff -r 56cf0f1772f7 linux/drivers/media/video/gspca/mr97310a.c --- a/linux/drivers/media/video/gspca/mr97310a.c Mon Mar 23 19:18:34 2009 -0300 +++ b/linux/drivers/media/video/gspca/mr97310a.c Fri Mar 27 01:42:28 2009 +0300 @@ -347,8 +347,10 @@ /* -- module insert / remove -- */ static int __init sd_mod_init(void) { - if (usb_register(&sd_driver) < 0) - return -1; + int ret; + ret = usb_register(&sd_driver); + if (ret < 0) + return ret; PDEBUG(D_PROBE, "registered"); return 0; }