From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Michal Nazarewicz <mnazarewicz@google.com>,
Felipe Balbi <balbi@ti.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Yang Rui Rui <ruirui.r.yang@tieto.com>,
Dave Young <hidave.darkstar@gmail.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv5 1/4] usb: Provide usb_speed_string() function
Date: Fri, 26 Aug 2011 11:34:50 -0700 [thread overview]
Message-ID: <20110826183450.GA32142@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1108261422460.2275-100000@netrider.rowland.org>
On Fri, Aug 26, 2011 at 02:26:43PM -0400, Alan Stern wrote:
> On Fri, 26 Aug 2011, Greg KH wrote:
>
> > > --- a/drivers/usb/Makefile
> > > +++ b/drivers/usb/Makefile
> > > @@ -53,3 +53,5 @@ obj-$(CONFIG_USB_MUSB_HDRC) += musb/
> > > obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
> > > obj-$(CONFIG_USB_OTG_UTILS) += otg/
> > > obj-$(CONFIG_USB_GADGET) += gadget/
> > > +
> > > +obj-$(CONFIG_USB_SUPPORT) += common.o
> >
> > You just built this into the kernel, which while ok for some things,
> > might not be what some people want.
> >
> > Please make this into a separate module if people are building the usb
> > code as modules, usb_common.ko perhaps?
>
> > > +#ifdef __KERNEL__
> > > +
> > > +/**
> > > + * usb_speed_string() - Returns human readable-name of the speed.
> > > + * @speed: The speed to return human-readable name for. If it's not
> > > + * any of the speeds defined in usb_device_speed enum, string for
> > > + * USB_SPEED_UNKNOWN will be returned.
> > > + */
> > > +extern const char *usb_speed_string(enum usb_device_speed speed);
> > > +
> > > +#endif
> >
> > No, this should be in include/linux/usb.h, not ch9.h.
>
> There's a reason for both of these things. The usb_speed_string
> routine, like the other stuff in ch9.h, is meant to be used with both
> the host-side and device-side USB stacks.
Ok, the __KERNEL__ stuff threw me off, those should not be in the patch
as they are not needed, so it's ok to keep it here, sorry.
> This makes deciding where to put it kind of difficult. The two stacks
> are pretty much independent; one might be built into the kernel while
> the other is built as modules. The easiest solution that will always
> work is to put common.c into the main kernel.
A module, if the USB Host core is a module, and a module if the USB
gadge core is a module, would be best if at all possible. I'm a bit
leery of adding stuff to be built into the kernel no matter how the user
decided to configure USB.
Is this possible with the Kbuild system somehow?
thanks,
greg k-h
next prev parent reply other threads:[~2011-08-26 18:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 13:18 [PATCHv5 0/4] Removing USB_GADGET_*SPEED macros Michal Nazarewicz
2011-08-26 13:18 ` [PATCHv5 1/4] usb: Provide usb_speed_string() function Michal Nazarewicz
2011-08-26 18:07 ` Greg KH
2011-08-26 18:26 ` Alan Stern
2011-08-26 18:34 ` Greg KH [this message]
2011-08-26 18:49 ` Alan Stern
2011-08-26 18:57 ` Michal Nazarewicz
2011-08-26 20:46 ` Alan Stern
2011-08-30 15:11 ` [PATCHv5.1 " Michal Nazarewicz
2011-08-26 13:18 ` [PATCHv5 2/4] usb: gadget: replace "is_dualspeed" with "max_speed" Michal Nazarewicz
2011-09-09 14:14 ` Michal Nazarewicz
2011-10-06 9:27 ` Felipe Balbi
2011-10-10 6:02 ` Felipe Balbi
2011-10-10 6:22 ` Dave Young
2011-10-10 7:40 ` Michal Nazarewicz
2011-10-10 7:42 ` Felipe Balbi
2011-08-26 13:18 ` [PATCHv5 3/4] usb: gadget: rename usb_gadget_driver::speed to max_speed Michal Nazarewicz
2011-10-10 6:02 ` Felipe Balbi
2011-08-26 13:18 ` [PATCHv5 4/4] usb: gadget: get rid of USB_GADGET_{DUAL,SUPER}SPEED Michal Nazarewicz
2011-10-10 6:02 ` Felipe Balbi
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=20110826183450.GA32142@kroah.com \
--to=greg@kroah.com \
--cc=balbi@ti.com \
--cc=bigeasy@linutronix.de \
--cc=hidave.darkstar@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mnazarewicz@google.com \
--cc=ruirui.r.yang@tieto.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox