public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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