Message ID | 1240171389.12537.3.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: Sun, 19 Apr 2009 20:03:21 +0000 Received: from vger.kernel.org ([209.132.176.167]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1LvdEW-0003FB-LM; Sun, 19 Apr 2009 20:03:21 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757128AbZDSUDS (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Sun, 19 Apr 2009 16:03:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757307AbZDSUDS (ORCPT <rfc822;linux-media-outgoing>); Sun, 19 Apr 2009 16:03:18 -0400 Received: from mail-fx0-f158.google.com ([209.85.220.158]:47786 "EHLO mail-fx0-f158.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757128AbZDSUDR (ORCPT <rfc822;linux-media@vger.kernel.org>); Sun, 19 Apr 2009 16:03:17 -0400 Received: by fxm2 with SMTP id 2so1649989fxm.37 for <linux-media@vger.kernel.org>; Sun, 19 Apr 2009 13:03:15 -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=ji4FHaykxqkmU3CwwciSREeBYDnnUQTAff5D62K/7eg=; b=KBmrWo8Zu1B7UTVAW01NtO8HkeLBc92ZLsGATOuGdoNqwHvNRugfIHNj7FSxSDusME gPvr7uDfh9y518zi4y/iDqaJc8IK7EAZ8FkNxfu1kmOI2diHz08ih+N3m7OPxkQEbxXu bnJ6jqRm9y01QinQhjyZHuai5MPwQw1sosop0= 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=BU1d3y6MtMnRDXTZKjpNNeOu0WFR3L+mzLm5+/5wkunZXhsJrDrY4v0xng5ddHifhu YZRtVuE5YRsS51axoAzD3ohN1nl3mdyhaHaFVlXso08Jetuh8E9VjuyzjpR1NhyTyXkj XZhYkUkAby8FPHzOXLoQajaJ+3E/vafW3wpbk= Received: by 10.86.95.8 with SMTP id s8mr3481411fgb.24.1240171395664; Sun, 19 Apr 2009 13:03:15 -0700 (PDT) Received: from ?192.168.1.42? (gw.zunet.ru [217.67.117.64]) by mx.google.com with ESMTPS id l19sm3592343fgb.6.2009.04.19.13.03.14 (version=SSLv3 cipher=RC4-MD5); Sun, 19 Apr 2009 13:03:15 -0700 (PDT) Subject: [patch review] uvc_driver: fix compile warning From: Alexey Klimov <klimov.linux@gmail.com> To: Laurent Pinchart <laurent.pinchart@skynet.be>, Mauro Carvalho Chehab <mchehab@infradead.org> Cc: linux-media@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl> Content-Type: text/plain Date: Mon, 20 Apr 2009 00:03:09 +0400 Message-Id: <1240171389.12537.3.camel@tux.localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 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
April 19, 2009, 8:03 p.m. UTC
Hello, all
I saw warnings in v4l-dvb daily build.
May this patch be helpful?
Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
--
Comments
Hi Alexey, On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote: > Hello, all > I saw warnings in v4l-dvb daily build. > May this patch be helpful? I can't reproduce the problem with gcc 4.3.2. Hans, what's the policy for fixing gcc-related issues ? Should the code use uninitialized_var() to make every gcc version happy, or can ignore the warnings when a newer gcc version fixes the problem > Signed-off-by: Alexey Klimov <klimov.linux@gmail.com> > > -- > diff -r cda79523a93c linux/drivers/media/video/uvc/uvc_driver.c > --- a/linux/drivers/media/video/uvc/uvc_driver.c Thu Apr 16 18:30:38 2009 > +0200 +++ b/linux/drivers/media/video/uvc/uvc_driver.c Sun Apr 19 23:58:02 > 2009 +0400 @@ -1726,7 +1726,7 @@ > static int __uvc_resume(struct usb_interface *intf, int reset) > { > struct uvc_device *dev = usb_get_intfdata(intf); > - int ret; > + int ret = 0; > > uvc_trace(UVC_TRACE_SUSPEND, "Resuming interface %u\n", > intf->cur_altsetting->desc.bInterfaceNumber); Laurent Pinchart -- 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
On Mon, 20 Apr 2009 19:25:00 +0200 Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > Hi Alexey, > > On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote: > > Hello, all > > I saw warnings in v4l-dvb daily build. > > May this patch be helpful? > > I can't reproduce the problem with gcc 4.3.2. > > Hans, what's the policy for fixing gcc-related issues ? Should the code use > uninitialized_var() to make every gcc version happy, or can ignore the > warnings when a newer gcc version fixes the problem Laurent, The kernel way is to use unitialized_var() on such cases. Personally, I don't like very much this approach, since it will get rid forever of such error for that var. However, a future patch could make that var truly uninitialized. So, an extra care should be taken on every patch touching a var that uses uninitialized_var() macro. From my side, I accept patches with both ways to fix it. Cheers, Mauro -- 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
Hi Mauro, On Monday 20 April 2009 19:50:31 Mauro Carvalho Chehab wrote: > On Mon, 20 Apr 2009 19:25:00 +0200 > > Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > > Hi Alexey, > > > > On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote: > > > Hello, all > > > I saw warnings in v4l-dvb daily build. > > > May this patch be helpful? > > > > I can't reproduce the problem with gcc 4.3.2. > > > > Hans, what's the policy for fixing gcc-related issues ? Should the code > > use uninitialized_var() to make every gcc version happy, or can ignore > > the warnings when a newer gcc version fixes the problem > > Laurent, > > The kernel way is to use unitialized_var() on such cases. > > Personally, I don't like very much this approach, since it will get rid > forever of such error for that var. However, a future patch could make that > var truly uninitialized. So, an extra care should be taken on every patch > touching a var that uses uninitialized_var() macro. > > From my side, I accept patches with both ways to fix it. I wasn't talking about ' = 0' vs. 'uninitialized_var()', but rather about submitting a patch vs. considering the problem fixed because gcc 4.3.2 doesn't spit a warning while gcc 4.3.1 does. Cheers, Laurent Pinchart -- 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
On Mon, 20 Apr 2009 22:12:47 +0200 Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > Hi Mauro, > > On Monday 20 April 2009 19:50:31 Mauro Carvalho Chehab wrote: > > On Mon, 20 Apr 2009 19:25:00 +0200 > > > > Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > > > Hi Alexey, > > > > > > On Sunday 19 April 2009 22:03:09 Alexey Klimov wrote: > > > > Hello, all > > > > I saw warnings in v4l-dvb daily build. > > > > May this patch be helpful? > > > > > > I can't reproduce the problem with gcc 4.3.2. > > > > > > Hans, what's the policy for fixing gcc-related issues ? Should the code > > > use uninitialized_var() to make every gcc version happy, or can ignore > > > the warnings when a newer gcc version fixes the problem > > > > Laurent, > > > > The kernel way is to use unitialized_var() on such cases. > > > > Personally, I don't like very much this approach, since it will get rid > > forever of such error for that var. However, a future patch could make that > > var truly uninitialized. So, an extra care should be taken on every patch > > touching a var that uses uninitialized_var() macro. > > > > From my side, I accept patches with both ways to fix it. > > I wasn't talking about ' = 0' vs. 'uninitialized_var()', but rather about > submitting a patch vs. considering the problem fixed because gcc 4.3.2 doesn't > spit a warning while gcc 4.3.1 does. Since 4.3.1 is a supported gcc version, it is better to fix the warning for it. Cheers, Mauro -- 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 cda79523a93c linux/drivers/media/video/uvc/uvc_driver.c --- a/linux/drivers/media/video/uvc/uvc_driver.c Thu Apr 16 18:30:38 2009 +0200 +++ b/linux/drivers/media/video/uvc/uvc_driver.c Sun Apr 19 23:58:02 2009 +0400 @@ -1726,7 +1726,7 @@ static int __uvc_resume(struct usb_interface *intf, int reset) { struct uvc_device *dev = usb_get_intfdata(intf); - int ret; + int ret = 0; uvc_trace(UVC_TRACE_SUSPEND, "Resuming interface %u\n", intf->cur_altsetting->desc.bInterfaceNumber);