From: Greg KH <gregkh@suse.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] [PATCH 02/02] USB: add dynamic id functionality to USB core
Date: Thu, 17 Nov 2005 08:25:33 -0800 [thread overview]
Message-ID: <20051117162533.GB26824@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0511171049070.5089-100000@iolanthe.rowland.org>
On Thu, Nov 17, 2005 at 10:55:33AM -0500, Alan Stern wrote:
> A few minor comments...
>
> On Wed, 16 Nov 2005, Greg KH wrote:
>
> > +static ssize_t store_new_id(struct device_driver *driver,
> > + const char *buf, size_t count)
> > +{
> > + struct usb_driver *usb_drv = to_usb_driver(driver);
> > + struct usb_dynid *dynid;
> > + u32 idVendor = 0;
> > + u32 idProduct = 0;
> > + int fields = 0;
> > +
> > + fields = sscanf(buf, "%x %x", &idVendor, &idProduct);
> > + if (fields < 0)
> > + return -EINVAL;
>
> Don't you want to test (fields < 2)?
No, it's ok to just specify the vendor, if you want a product of 0 :)
PCI does it this way too.
> > + if (get_driver(&usb_drv->driver)) {
> > + driver_attach(&usb_drv->driver);
> > + put_driver(&usb_drv->driver);
> > + }
>
> Here you don't have to refer to &usb_drv->driver; you can just refer to
> driver.
Good point, changed, thanks.
> > +static int usb_create_newid_file(struct usb_driver *usb_drv)
> > +{
> > + int error = 0;
> > +
> > + if (usb_drv->probe != NULL)
> > + error = sysfs_create_file(&usb_drv->driver.kobj,
> > + &driver_attr_new_id.attr);
> > + return error;
> > +}
>
> This deserves to be an inline function.
>
> > +static void usb_free_dynids(struct usb_driver *usb_drv)
> > +{
> > + struct usb_dynid *dynid, *n;
> > +
> > + spin_lock(&usb_drv->dynids.lock);
> > + list_for_each_entry_safe(dynid, n, &usb_drv->dynids.list, node) {
> > + list_del(&dynid->node);
> > + kfree(dynid);
> > + }
> > + spin_unlock(&usb_drv->dynids.lock);
> > +}
>
> This could be inline as well, although being longer, its overhead is less
> noticeable.
It's just not worth it to inline these, it's not speed critical at all.
I prefer to not inline stuff unless it help out somehow.
thanks for the review,
greg k-h
next prev parent reply other threads:[~2005-11-17 17:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 0:30 [PATCH 00/02] [RFC] Add dynamic id support to all USB drivers Greg KH
2005-11-17 0:31 ` [PATCH 01/02] USB: reorg some functions out of the main usb.c file Greg KH
2005-11-17 0:32 ` [PATCH 02/02] USB: add dynamic id functionality to USB core Greg KH
2005-11-17 15:55 ` [linux-usb-devel] " Alan Stern
2005-11-17 16:25 ` Greg KH [this message]
2005-11-17 17:19 ` Alan Stern
2005-11-18 1:09 ` Greg KH
2005-11-17 19:58 ` Ingo Oeser
2005-11-18 1:39 ` 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=20051117162533.GB26824@suse.de \
--to=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
/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.