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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0808291307050.4447-100000@netrider.rowland.org>
Date:	Fri, 29 Aug 2008 13:19:09 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Scott Wood <scottwood@...escale.com>,
	<dbrownell@...rs.sourceforge.net>, <greg@...ah.com>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linuxppc-dev@...abs.org>, Li Yang <leoli@...escale.com>
Subject: Re: [PATCH] usb: add Freescale QE/CPM USB peripheral controller
 driver

On Fri, 29 Aug 2008, Arnd Bergmann wrote:

> 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.

I thought you _were_ arguing against that.  Unless I misunderstood,
your original complaint was that since each peripheral controller
driver defines usb_gadget_{un}register_driver, there can be only one
controller driver loaded at a time.

However see below...

> 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.

It's a new feature, only recently added to the kernel and not fully 
implemented yet.  The protocol handlers are encapsulated as "function" 
drivers, where multiple functions can be combined at link time into a 
single gadget.

> > > 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.

fsl_usb2_udc isn't a good example; its behavior is not typical.  Other
peripheral hardware drivers behave differently -- they define a single
static structure (or a dynamic singleton structure) and expect the
platform to contain no more than one matching device.  Look at
lh7a40x_udc.c for a more typical example.

> 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.

I see your point.  Even worse, you can't build both of them as modules.

Personally I wouldn't mind relaxing the "one interface per device" 
rule.  But I'm not the Gadget maintainer...

(There is another problem.  If you have multiple peripheral interfaces,
how would you specify which one a particular gadget driver should bind
to?)

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/