Hi, Jassi Brar <jassisinghbrar@xxxxxxxxx> writes: > On Wed, Oct 14, 2015 at 8:42 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> >> Hi, >> >> jaswinder.singh@xxxxxxxxxx writes: >>> From: Jassi Brar <jaswinder.singh@xxxxxxxxxx> >>> >>> We must return 0 for any OUT setup request, otherwise >>> protocol error may occur. >> >> have you seen any such errors ? >> > Yes. While testing my new udc driver. > > >> Care to describe what problems you have seen and which UDC you were using, >> what's the exact scenario. How have you tested this ? >> > The udc I am writing the driver for is not yet public. To test my > driver at lowest level possible, I use 'usbmon' to capture and analyze > traffic since I don't have any hardware probe. > > I see the following on gadget side > ------- > configfs-gadget gadget: non-core control req21.20 v0000 i0001 l7 > configfs-gadget gadget: acm ttyGS0 req21.20 v0000 i0001 l7 > configfs-gadget gadget: acm ttyGS0 completion, err -71 > ------- > > and the following on host side usbmon capture > ------- > ffff88041ed01f00 540296433 S Co:3:023:0 s 21 20 0000 0001 0007 7 = > 80250000 000008 > ffff88041ed01f00 540296790 C Co:3:023:0 -71 0 > ------- and you did you even consider this could be a bug in your new UDC driver at all ? This works fine with other UDCs. How far are you in developing this new UDC driver ? Did you run USBCV at all ? Are you sure you're implementing EP0 handling correctly ? What sort of tests have you done with this UDC ? Is it working with testusb against a known good host (EHCI and XHCI should be good for that) ? -- balbi
Attachment:
signature.asc
Description: PGP signature