Hello, On Mon, 23 Jan 2017 14:00:40 +0200, Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> wrote: > it could be that we're ran out of IN endpoints. There's a maximum number > to how many IN endpoints we can have enabled at one time and, currently, > dwc3 is not enforcing that in any way (I'll get that sorted out for > v4.12, v4.11 is already too late) 8OUT failing also caught my eye, which is the only OUT endpoint failing. And it happens when ep_addr & 0x7 == 0. Could something (hardware ?) be confused and handle this as a kind of EP0 ? Then, there would be 3 patterns to my uneducated eye: - 15IN and several downward would fail because of the dwc3 active IN endpoint limit you mention - 8IN and 8OUT would fail for some aliasing-with-EP0 reason - 1IN and 9IN may fail for a related reason (depending on where the IN endpoint limit exactly stands - 8 or 9 I guess - and whether EP0 counts towards the limit) BTW, I also checked what my protocol analyser says in this 30-endpoints version, but the result is quite boring: - all (failing) IN endpoints NAK - the one failing OUT endpoint NAKs the first attempt, then follows the PING protocol (MAK'ing all PINGs until the 0.2s timeout I set in the host test app). Addresses are properly transmitted (ie, it's not on bus level that EP8 would get aliased). I still could not find the time to rebuild my machine's kernel on your xhci-cleanup branch, so I'm still on 4.8.11 from a bit outdated Debian sid package). I also noticed your commit about dwc3 having problems when clearing halt of an already non-halted endpoint (and reciprocally), and I do clear halts in the device test program. I tried commenting that out in my program and merging your testing/next branch in my working copy, without any improvement. Regards, -- Vincent Pelletier
Attachment:
pgpRAz8noE9zV.pgp
Description: Signature digitale OpenPGP
