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

> > > +	/* NOTE:  most peripheral controller drivers won't bother
> > > +	 * registering the gadget drivers, since doing that requires
> > > +	 * that the driver be associated with a bus.  There's really
> > > +	 * no existing bus that's appropriate for a gadget driver,
> > > +	 * and little point in defining a "bus" that must never have
> > > +	 * more than one device.
> > > +	 */
> > >  	driver->driver.bus = dum->gadget.dev.parent->bus;
> > >  	if ((retval = driver_register (&driver->driver)) != 0)
> > >  		goto err_register;
> > 
> > Now that I look back on it, it's not so clear that the scheme used by
> > dummy_hcd is really correct.  It registers a driver structure on the
> > platform bus but embeds it inside a usb_gadget_driver instead of a
> > platform_driver.  This sounds like a bug waiting to happen.

True.  ISTR the platform bus will do things like convert the driver
struct into a platform_driver and then use the platform_bus methods
out of those structs ... which would in this case be garbage.

The last bugs I recall fixing in that area involved suspend/resume
methods which didn't exist getting called through that garbage.


> > Maybe it would be better to change dummy_hcd to make it work like the
> > other device controller drivers.

Certainly such oops avoidance would be good.  ;)

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


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

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.


> > 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?  :)

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


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


> All the kset/ktype rework was because of this...

Now I *really* don't follow...

- Dave

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