linux-kernel - Re: [PATCH/RFC 2/5] usb:dummy_hcd: connect/disconnect test support

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.1106161315510.1690-100000@iolanthe.rowland.org>
Date:	Thu, 16 Jun 2011 13:19:49 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Balbi <balbi@...com>
cc:	Tatyana Brokhman <tlinder@...eaurora.org>, <greg@...ah.com>,
	<linux-usb@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
	<ablay@...eaurora.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH/RFC 2/5] usb:dummy_hcd: connect/disconnect test support

On Thu, 16 Jun 2011, Alan Stern wrote:

> On Thu, 16 Jun 2011, Felipe Balbi wrote:
> 
> > Hi,
> > 
> > On Thu, Jun 16, 2011 at 11:06:47AM -0400, Alan Stern wrote:
> > > On Thu, 16 Jun 2011, Tatyana Brokhman wrote:
> > > 
> > > > This implementation adds a new proprietary device control requests (to be
> > > > handled by the dummy_hcd) that initiates a connect/disconnect sequence.
> > > > The bRequest value of the new control request is 0x52.
> > > > It is used by the user-space Unit testing application.
> > > 
> > > This is not a bad idea.  On the other hand, it is slightly peculiar -- 
> > > it you're testing with real UDC hardware, you would do the 
> > > disconnect/reconnect sequence by hand (unplug and replug the USB 
> > > cable), not in software.
> > 
> > actually, this is quite useful. Specially for the controllers which
> > _can_ do soft-connect by toggling data pullups. I would rather have
> > these sort of thing maybe in composite.c, so that we can build tests
> > with all gadget drivers/controllers, not only dummy_hcd.
> 
> It sounds like you don't understand the point of this patch.  It allows
> the _host_ to control the pullup settings.

Sorry, the misunderstanding was mine -- I didn't grasp what you were 
suggesting.

Yes, something like this could be useful in composite.c.  It could be 
defined as a vendor-specific request with the device as the recipient.  

One problem with making it special for dummy-hcd is that it would 
prevent people from testing gadget drivers that want to use the same 
bRequest value to mean something different.  Putting it in composite.c 
would force all function drivers to know about it.

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/