Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller driver

[Arnd Bergmann <arnd@arndb.de>]

On Friday 29 August 2008, Alan Stern wrote:
> > The standard requires that there can only be one protocol handler
> > per physical interface, which is a reasonable limitation.
> 
> No, you've got it exactly backward.  There can be multiple protocol 
> handlers per physical interface, but there must be only one physical 
> interface per device.

Maybe I am using wrong terminology, but I still don't see how that
fits together. Let me try to explain what I have understood so far:

The physical device is identified by a struct usb_gadget is defined
statically in the driver that exports the
usb_gadget_{un,}register_driver() functions. Obviously there can only
be one physical interface per physical device, I was not arguing
against that.

The protocol handler is identified by a usb_gadget_driver and defined
in a driver that calls usb_gadget_register_driver().
You say that there can be multiple protocol handlers, which I don't
understand because the protocol handlers all call set_gadget_data,
which overwrites the previous driver_data field in struct usb_gadget,
making it impossible to load more than one simultaneously.
 
> > However, what the Linux implementation actually enforces is
> > that there can only be one hardware specific driver built or loaded
> > into the kernel, which just looks like an arbitrary restriction
> > that does not actually help.
> 
> Not at all -- it is an implementation of the constraint that there be 
> only one physical interface.

How that? Taking drivers/usb/gadget/fsl_usb2_udc.c as an example, it will
create a new fsl_udc structure for each matching platform_device it finds
(though it will leak every one except the last one), so the interface
does not limit the number of physical interfaces at all to this point,
the implementation of the every gadget hardware driver does this.

The real problem is that you cannot build a kernel that has both
fsl_usb2_udc.c and fsl_qe_udc.c built in. Having both drivers loaded
would not violate the one-interface rule, because only one of them
would find hardware to bind to on a given system, just like you can
load both the uhci and ohci drivers without them interfering.

	Arnd <><