From: Valdis.Kletnieks@vt.edu
To: "Justin P. Mattock" <justinmattock@gmail.com>
Cc: linux-usb@vger.kernel.org, dbrownell@users.sourceforge.net,
gregkh@suse.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2]drivers/usb/core/sysfs.c Fix variable 'retval' set but not used
Date: Tue, 03 Aug 2010 07:28:25 -0400 [thread overview]
Message-ID: <58611.1280834905@localhost> (raw)
In-Reply-To: Your message of "Mon, 02 Aug 2010 21:26:28 PDT." <1280809589-23649-1-git-send-email-justinmattock@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Mon, 02 Aug 2010 21:26:28 PDT, "Justin P. Mattock" said:
> diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
> if (alt->string)
> - retval = device_create_file(&intf->dev, &dev_attr_interface);
> + device_create_file(&intf->dev, &dev_attr_interface);
> intf->sysfs_files_created = 1;
> return 0;
What should the code do if device_create_file() manages to fail? Yes, ignoring
the return value is one option, but is it the best one? 'return ret;' might be
another one. Somebody who understands this code and has more caffeine than me
should look this over.
(Nothing personal Justin - it's just my opinion that *anytime* we have a patch
that remove a check for a return code, it needs to justify that ignoring the
return code is appropriate).
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2010-08-03 11:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 4:26 [PATCH 1/2]drivers/usb/core/sysfs.c Fix variable 'retval' set but not used Justin P. Mattock
2010-08-03 4:26 ` [PATCH 2/2]drivers/usb/host/ehci-hub.c Fix variable 'i' " Justin P. Mattock
2010-08-03 11:28 ` Valdis.Kletnieks [this message]
2010-08-03 13:30 ` [PATCH 1/2]drivers/usb/core/sysfs.c Fix variable 'retval' " Justin P. Mattock
2010-08-03 14:29 ` Alan Stern
2010-08-03 14:43 ` Justin P. Mattock
2010-08-03 15:36 ` Alan Stern
2010-08-03 16:12 ` Justin P. Mattock
2010-08-03 15:13 ` Valdis.Kletnieks
2010-08-03 15:34 ` Alan Stern
2010-08-03 15:46 ` Greg KH
2010-08-03 17:09 ` Alan Stern
2010-08-03 17:22 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58611.1280834905@localhost \
--to=valdis.kletnieks@vt.edu \
--cc=dbrownell@users.sourceforge.net \
--cc=gregkh@suse.de \
--cc=justinmattock@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.