On Mon, 16 Jan 2017 09:06:20 +0200, Felipe Balbi
<felipe.balbi@xxxxxxxxxxxxxxx> wrote:
> it's actually pretty important :-)
Will do then, although maybe not before this week-end.
There is something I do not get about this though: the protocol
analyser does find IN tokens directed at the right device address,
endpoint 1. So I think the host controller is doing its job just fine.
It is the device controller which somehow does not do whatever it is
supposed to do to pick the data buffer which is already sitting there,
waiting to be pushed on the bus...
I made a few more debugging attempts:
1) I made device.py arm ep1in stall, which did affect ep1in transfers
(making them fail instantaneously, instead of letting host reach its
5s timeout). ep1out and ep2in were working properly (ie, not
stalled). So exactly one endpoint was affected, and the expected one.
Looks like ep1in has issues with IN transfers (at least BULK ones, I
did not try other types yet).
2) I replaced two INs, one OUT with just two INs: ep1in is silent,
ep2in works.
Likewise, with three INs, only ep1in is silent, 2in and 3in work.
3) I declared 4 endpoints (2 IN, 2 OUT). And I went one level deeper
down the rabbit hole: now enumeration fails with this message on
host:
Jan 16 13:37:04 localhost kernel: [268765.354184] usb 1-10: config 1 interface 0 altsetting 0 has 3 endpoint descriptors, different from the interface descriptor's value: 4
So, protocol analyser time it is again, and I found this beast of a
configuration descriptor:
000:36.013'125"200n IN @021.00 DATA1 46B ACK
000 09 02 2e 00 01 01 04 80 fa 07 05 01 02 00 02 00 ................
010 09 04 00 00 04 ff 00 00 05 07 05 81 02 00 02 00 ................
020 07 05 02 02 00 02 00 07 05 82 02 00 02 00 ..............
000 09 02: configuration descriptor.
00a 07 05: endpoint descriptor (ep1out). <- WTF ?!
010 09 04: interface descriptor.
01a 07 05: endpoint descriptor (ep1in).
020 07 05: endpoint descriptor (ep2out).
027 07 05: endpoint descriptor (ep2in).
I checked thrice that I am writing the descriptors in the correct
order (interface before all endpoints), both on FS and HS
configurations, in consistent order, and with consistent endpoint
numbers. Also it is not a FS edpoint as their wMaxPacketSize is 64[1].
The same happens with 4 IN endpoints, one (0x81) gets in front of the
interface descriptor. Maybe f_fs.c reordering descriptors ? More
debugging for another day...
If something is reordering descriptors, then it means my assumption
that initialising ep1in before or after ep1out does not make a
difference may have been misguided.
[1] By the way, functionfs produces non-standard descriptors when no
full-speed descriptors are given: the first (in fs, hs, ss order) list
of endpoints gets passed to usb_ep_autoconfig[_ss](), which limits
wMaxPacketSize to 64. Took me a while to figure several weeks ago. If
that API allowed passing descriptor's speed around it would be
possible, but that's way over my head at the moment - and not a blocker
anyway.
--
Vincent Pelletier
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
