Re: [linux-usb-devel] Re: [PATCH] reorganize USB submenu's

[David Brownell <david-b@pacbell.net>]

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
>  #
> -choice
> -	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.
>  
> -endchoice

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?

- Dave