I'm trying to pass testusb suite test on a UDC driver. It fails when
running test 10:
$ ./testusb -t10 -D /proc/bus/usb/002/016
unknown speed /proc/bus/usb/002/016
/proc/bus/usb/002/016 test 10 --> 75 (error 75)
It actually fails while running case 10 and it seems to tes
On Fri, 24 Mar 2006, Franck Bui-Huu wrote:
> I'm trying to pass testusb suite test on a UDC driver. It fails when
> running test 10:
>
> $ ./testusb -t10 -D /proc/bus/usb/002/016
> unknown speed /proc/bus/usb/002/016
> /proc/bus/usb/002/016 test 10 --> 75 (error 75)
>
> It ac
2006/3/24, Alan Stern <[EMAIL PROTECTED]>:
> On Fri, 24 Mar 2006, Franck Bui-Huu wrote:
> This output is very meager.
sorry I forgot to mention that it was snipped. Here is a more complete one:
d5161c80 2492837178 S Co:014:00 -115 0
d5161c80 2492892431 C Co:014:00 0 0
d7aa5180 2492892503 S Ci:014
On Fri, 24 Mar 2006, Franck Bui-Huu wrote:
> I made a mistake, it's not case 10 that failed but rather case 11.
> This case ask for 9 bytes but the device answer with 32 bytes, thus
> the EOVERFLOW status given by the host. If I remember well, the device
> should stall in that case, but the zero d
2006/3/24, Alan Stern <[EMAIL PROTECTED]>:
> Case 11 asks for an endpoint descriptor, which is an illegal request.
> zero.c returns -EOPNOTSUPP from zero_setup(), so the UDC driver should
> STALL the endpoint.
>
Ah...didnt know that point sorry.
I got 2 more questions, hope you don't mind.
Can I
On Sun, 26 Mar 2006, Franck Bui-Huu wrote:
> I got 2 more questions, hope you don't mind.
>
> Can I assert that the ep0's request queue has always one request queued ?
No, of course not. Most of the time there won't be any requests queued.
On ep0, requests are queued only in response to Setup
2006/3/26, Alan Stern <[EMAIL PROTECTED]>:
> On Sun, 26 Mar 2006, Franck Bui-Huu wrote:
>
> > I got 2 more questions, hope you don't mind.
> >
> > Can I assert that the ep0's request queue has always one request queued ?
>
> No, of course not. Most of the time there won't be any requests queued.
>
On Sun, 26 Mar 2006, Franck Bui-Huu wrote:
> sorry the question wasn't accurate, I would have asked: am I sure that
> the driver will queue only one request in a response to a SETUP
> packet ? that would mean the request queue for ep0 has no more than
> one request at any time.
You shouldn't ass
On Sunday 26 March 2006 9:11 am, Alan Stern wrote:
> On Sun, 26 Mar 2006, Franck Bui-Huu wrote:
>
> > sorry the question wasn't accurate, I would have asked: am I sure that
> > the driver will queue only one request in a response to a SETUP
> > packet ? that would mean the request queue for ep0 h
On Thu, 30 Mar 2006, David Brownell wrote:
> On Sunday 26 March 2006 9:11 am, Alan Stern wrote:
> > On Sun, 26 Mar 2006, Franck Bui-Huu wrote:
> >
> > > sorry the question wasn't accurate, I would have asked: am I sure that
> > > the driver will queue only one request in a response to a SETUP
>
On Thursday 30 March 2006 1:55 pm, Alan Stern wrote:
> On Thu, 30 Mar 2006, David Brownell wrote:
> >
> > Actually, I'd say it's OK to assume that. It's an error if the
> > gadget driver issues more than one response to a setup() callback,
> > or issues a response when no setup() is pending.
>
>
On Thu, 30 Mar 2006, David Brownell wrote:
> On Thursday 30 March 2006 1:55 pm, Alan Stern wrote:
> > On Thu, 30 Mar 2006, David Brownell wrote:
> > >
> > > Actually, I'd say it's OK to assume that. It's an error if the
> > > gadget driver issues more than one response to a setup() callback,
> >
On Friday 31 March 2006 7:18 am, Alan Stern wrote:
> On Thu, 30 Mar 2006, David Brownell wrote:
>
> > On Thursday 30 March 2006 1:55 pm, Alan Stern wrote:
> > > On Thu, 30 Mar 2006, David Brownell wrote:
> > > >
> > > > Actually, I'd say it's OK to assume that. It's an error if the
> > > > gadge
On Fri, 31 Mar 2006, David Brownell wrote:
> > > The "one response" rule is simple and easy to implement and
> > > explain. Anything else would be complex, and thus error prone.
> >
> > But there's nothing in the gadget API that says a driver can't split its
> > response between two buffers.
>
14 matches
Mail list logo
