RE: [PATCH v12 7/8] usb: Adding SuperSpeed support to dummy_hcd

[Alan Stern]

On Thu, 26 May 2011, Tanya Brokhman wrote:

> > > Right, but at this point there is no way of knowing what function
> > drivers
> > > will bind to it and what descriptors they will provide. Most of the
> > > function drivers allocate their descriptors at bind() that occurs
> > after
> > > the UDC already registers.
> > 
> > Well, there must be an appropriate spot to do this.
> 
> Unfortunately in the current implementation there isn't.

Sure there is.  You describe a good possibility later on in your 
email...

> > It looks like you need to add a "max_speed" field to struct
> > usb_composite_driver.  Each driver will initialize this to the highest
> > speed it supports, and it must guarantee that the necessary descriptors
> > are available.
> 
> I also thought of that. This can be done...
> Just to make sure we're on the same page:
> We can add a "max_sup_speed" field to struct usb_composite_driver. Each of
> the Gadget drivers will set this field prior to calling
> usb_composite_probe(). Then, in usb_composite_probe(), we'll update the
> composite_driver.speed as follows:
> 
> 	composite_driver.speed = min(composite_driver.speed,
> driver->max_sup_speed);

Just call it max_speed.  You can mention in the kerneldoc that it is 
the maximum speed supported by the driver.

> Of course for SS we'll update the composite_driver.speed @ static struct
> usb_gadget_driver composite_driver, as we agreed with Felipe.
> 
> How does that sound? Felipe - it seems to me that these should cover your
> hesitations about updating the driver speed :)
> 
> Now that I think about it, the above will be true for HS as well. I mean the
> current speed of composite_driver is set always to HS but if there is a
> function driver that supports only FS then the above will update
> composite_driver.speed to FS.

That's right.  The same solution will work for both cases.

Alan Stern

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