Re: [patch 2.6.24-rc3] usb peripheral controller driver oops avoidance

On Mon, 19 Nov 2007, David Brownell wrote:

> What I'll do is remove dummy_hcd from the $SUBJECT patch entirely,
> and let you submit a patch updating that stuff.

Okay, good.

> > > There seems to be no advantage to 
> > > registering the gadget driver in sysfs (and some disadvantage in that
> > > the Gadget API doesn't match up well with normal bus-oriented probe and
> > > remove methods).
> 
> Well bind() sort of resembles probe(), and unbind() sort
> of resembles remove().

Sort of.  But gadget drivers expect to originate such calls themselves 
and would probably get confused if the calls came from outside.  For 
example, a manual unbind followed by rmmod isn't likely to work.
And gadget drivers initiate a bind all by themselves when they are 
loaded; they don't wait for a probe to come from the driver core.

> But the other operations don't make much sense.  Something
> like a setup() for example, or the USB suspend/resume
> notifications coming from the bus ... distinct from the
> system-wide ones.

The only other operations are shutdown, suspend, and resume.  I don't
know how useful shutdown would be, but suspend and resume certainly
make sense.  They tell the gadget driver that the peripheral's OS is
making a system sleep transition -- as opposed to the gadget
suspend/resume notifications, which describe events happening on the
USB bus.

> > > Greg, do you agree with that last sentence?
> > 
> > No, all "drivers" should show up in sysfs somewhere, right?  Otherwise
> > userspace doesn't know anything about them...
> 
> What would userspace need to know, though?  :)

Right now, the only thing userspace can do with drivers via sysfs is 
manual binding and unbinding, through the 
/sys/bus/.../drivers/.../[un]bind files.  Those are exactly the things 
that gadget drivers aren't prepared to deal with.

> > I'm slowly working toward allowing multiple devices to bind to the same
> > 'driver',
> 
> I don't follow; why would that matter?  Moreover, they can
> do that already.  I see multiple OHCI controller devices
> hooked up to a single OHCI driver on this system, for example.
> ISTR that particular behavior has always worked.

Right.  The problem here isn't multiple devices binding to a single
driver.  Instead we have a driver which is able to handle only one
device (and for which only one device will ever be present).

On the other hand, there's nothing to stop somebody from putting two 
net2280 cards into a PC.  The net2280 driver might not be able to 
handle it and the existing gadget drivers definitely couldn't handle 
it, but it's doable in principle.

> > so David's original objection should be taken care of soon. 
> 
> One original observation was that needing to define a bus
> for a singleton object ("gadget") was pointless.  There
> were other reasons to avoid entangling things in (then-new)
> driver model stuff at that time ... and in general, to avoid
> the creation of lots of mid-layer code-bloat attractors.

Apart from those other reasons, there still seems to be little point in 
registering a gadget driver with sysfs.  In fact, the only advantage I 
can see is the ability to receive system suspend and resume calls.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel