Re: [RFC/PATCH] usb: misc: introduce OTG & EH Test Driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 04, 2012 at 03:15:27PM -0400, Alan Stern wrote:
> On Mon, 4 Jun 2012, Felipe Balbi wrote:
> 
> > On Mon, Jun 04, 2012 at 11:19:06AM -0400, Alan Stern wrote:
> > > On Mon, 4 Jun 2012, Felipe Balbi wrote:
> > > 
> > > > This patch introduces support for test modes as
> > > > defined by the USB OTG & Embedded host Specification.
> > > > 
> > > > Note that we _must_ be able to suspend & resume ports
> > > > as we wish, so this driver depends on USB_SUSPEND and
> > > > makes use (well, somewhat abuses) usb autopm features
> > > > to achieve what we want.
> > > 
> > > Have you tested the autopm stuff?  I don't think it will work the way 
> > > you've got it.
> > 
> > well, since I don't have the device myself, someone from a testing lab
> > has tested this driver. Any ideas how to implement that part with Linux?
> > That's a hard-requirement for USB OTG Certification, btw.
> 
> Yes; it needs to be addressed.
> 
> I believe it will be best to bypass the runtime PM framework.  Either
> send the necessary requests directly to the parent hub, or let's add a
> test-mode API to the hub driver to do the same thing.

that would be much much nicer as it could also be extended later to
support USB[23]0CV test modes, so we could finaly run pre-certification
tests on Linux with an open source tool.

> In some ways this is simpler than an ordinary device suspend.  For 
> example, you're not concerned about remote wakeup, right?

that's correct.

> > > > +static void otg_eh_disconnect(struct usb_interface *intf)
> > > > +{
> > > > +	struct usb_device		*udev;
> > > > +
> > > > +	udev = interface_to_usbdev(intf);
> > > > +
> > > > +	usb_lock_device_for_reset(udev, intf);
> > > 
> > > You don't need the locking around usb_reset_device().  Disconnect 
> > > methods are called with the device lock already held.
> > 
> > Will remove, but it's not what the comment on that function states. Or
> > at least it was a little dubious.
> 
> The comment just above the function's kerneldoc has a slightly clearer 
> explanation.

missed that one (sigh). Will read it tomorrow.

tks

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux