On Tue, 13 Aug 2013, Jack Pham wrote:
In addition, we may want some of the work (though at this point I'm
not still clear on exactly what parts) to be moved into usbcore.
+1. I am open to suggestions on how best to achieve this. I have a
another patch in the for doing the same
On Mon, Aug 12, 2013 at 02:52:33PM -0400, Alan Stern wrote:
On Mon, 12 Aug 2013, Felipe Balbi wrote:
maybe a single callback for supporting 'testmodes' ? which receives the
test mode as argument ?
I don't have a clear picture of how you would apply such an approach to
this
On Tue, 13 Aug 2013, Felipe Balbi wrote:
That's not what I meant. Yes, the test-device driver knows what test
it wants to run, based on the VID/PID. I was asking how it would
communicate this knowledge to the HCD.
For example, it doesn't make sense to have a callback that means
On Tue, Aug 13, 2013 at 10:32:57AM -0500, Felipe Balbi wrote:
On Mon, Aug 12, 2013 at 02:52:33PM -0400, Alan Stern wrote:
On Mon, 12 Aug 2013, Felipe Balbi wrote:
anything that USB[23]0CV supports today. There are even link layer tests
for USB3 and a bunch of others. This
Hi,
On Fri, Aug 09, 2013 at 11:04:48AM -0400, Alan Stern wrote:
heh, it doesn't need to be entirely in the core. Core could have the
generic calls and HCDs could implement some callbacks, but I think quite
a bit of the code will be similar if we implement the same thing on all
On Mon, 12 Aug 2013, Felipe Balbi wrote:
maybe a single callback for supporting 'testmodes' ? which receives the
test mode as argument ?
I don't have a clear picture of how you would apply such an approach to
this case. There would have to be a way to tell the HCD to insert a
Hi,
On Thu, Jul 25, 2013 at 05:33:48PM -0400, Alan Stern wrote:
On Thu, Jul 25, 2013 at 03:44:20PM -0400, Alan Stern wrote:
On Thu, 25 Jul 2013, Greg KH wrote:
On Tue, Jul 02, 2013 at 08:13:52PM -0700, Jack Pham wrote:
From: Manu Gautam mgau...@codeaurora.org
The USB
On Fri, 9 Aug 2013, Felipe Balbi wrote:
Wait a minute, didn't we discuss a while back that these test features
should be built into usbcore so that we could have a usbcv clone for
linux ?
There's no way this can be built into the core. This test requires the
behavior of the host
Hi,
On Fri, Aug 09, 2013 at 10:37:50AM -0400, Alan Stern wrote:
Wait a minute, didn't we discuss a while back that these test features
should be built into usbcore so that we could have a usbcv clone for
linux ?
There's no way this can be built into the core. This test
On Fri, 9 Aug 2013, Felipe Balbi wrote:
heh, it doesn't need to be entirely in the core. Core could have the
generic calls and HCDs could implement some callbacks, but I think quite
a bit of the code will be similar if we implement the same thing on all
HCDs.
What generic calls
On Tue, Jul 02, 2013 at 08:13:52PM -0700, Jack Pham wrote:
From: Manu Gautam mgau...@codeaurora.org
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:
1) The host enumerates the test device with VID:0x1A0A, PID:0x0108
2) The host
On Thu, 25 Jul 2013, Greg KH wrote:
On Tue, Jul 02, 2013 at 08:13:52PM -0700, Jack Pham wrote:
From: Manu Gautam mgau...@codeaurora.org
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:
1) The host enumerates the test
On Thu, Jul 25, 2013 at 03:44:20PM -0400, Alan Stern wrote:
On Thu, 25 Jul 2013, Greg KH wrote:
On Tue, Jul 02, 2013 at 08:13:52PM -0700, Jack Pham wrote:
From: Manu Gautam mgau...@codeaurora.org
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
On Tue, Jul 02, 2013 at 08:13:52PM -0700, Jack Pham wrote:
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 2b70277..8e6dc09 100644
---
From: Manu Gautam mgau...@codeaurora.org
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:
1) The host enumerates the test device with VID:0x1A0A, PID:0x0108
2) The host sends the SETUP stage of a GetDescriptor(Device)
3) The device
15 matches
Mail list logo
