From: David Brownell <email@example.com>
To: Stephen Hemminger <firstname.lastname@example.org>
Cc: Charles Lepple <email@example.com>, Greg KH <firstname.lastname@example.org>,
Subject: Re: [linux-usb-devel] Re: [PATCH] reorganize USB submenu's
Date: Thu, 31 Jul 2003 14:07:35 -0700 [thread overview]
Message-ID: <3F298517.email@example.com> (raw)
Stephen Hemminger wrote:
> --- linux-2.5/drivers/usb/gadget/Kconfig 2003-06-05 10:04:40.000000000 -0700
> +++ usb/drivers/usb/gadget/Kconfig 2003-07-31 12:45:04.000000000 -0700
> @@ -35,9 +35,6 @@
> # USB Peripheral Controller Support
> - prompt "USB Peripheral Controller Support"
> - depends on USB_GADGET
> config USB_NET2280
> tristate "NetChip 2280 USB Peripheral Controller"
> @@ -54,21 +51,23 @@
> dynamically linked module called "net2280" and force all
> gadget drivers to also be dynamically linked.
Why do you want to remove that choice menu? By doing that,
you've enabled illegal configurations.
In this case: no more than one controller driver may be
linked, since USB devices have exactly one upstream link.
By detecting this at configuration time, the current menus
prevent a link-time error.
This choice could be improved (at this point I'd likely
desupport "dummy plus real controller as modules", and
the more troublesome cases it carries along with it), but
that's not how I'd do it.
> @@ -110,7 +109,7 @@
> config USB_ETH
> tristate "Ethernet Gadget"
> - depends on USB_GADGET && (USB_DUMMY_HCD || USB_NET2280 || USB_PXA250 || USB_SA1100)
> + depends on USB_GADGET_CONTROL
This approach allows illegal configurations too. The config-time
dependencies prevent compile-time errors, by only enabling the
configurations that are known to compile and work.
When an "au1x00_udc" controller is added, each gadget driver will
need to be modified to know about its endpoints and config quirks,
then tested. (And some gadget drivers won't be able to do that:
maybe they need lots of endpoints, or rely on config change events
that particular hardware disallows.) By allowing arbitrary driver
stacking, you'd be causing at least compile errors.
Likewise, when an "audio" gadget driver is added, it'll need testing
on each controller. And since SA1100 can never support iso transfers,
that configuration shouldn't even be allowed.
Both your proposed changes share a common feature: reducing the degree
to which illegal configurations are prevented. Is that intentional?
next prev parent reply other threads:[~2003-07-31 21:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-31 17:11 [PATCH] reorganize USB submenu's Stephen Hemminger
2003-07-31 17:45 ` Roman Zippel
2003-07-31 17:51 ` Greg KH
[not found] ` <firstname.lastname@example.org>
2003-07-31 19:50 ` Stephen Hemminger
2003-07-31 20:16 ` Greg KH
2003-07-31 21:14 ` Stephen Hemminger
2003-07-31 22:57 ` Stephen Hemminger
2003-07-31 21:07 ` David Brownell [this message]
2003-07-31 21:18 ` [linux-usb-devel] " Stephen Hemminger
2003-07-31 22:00 ` David Brownell
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).