Now the PC detects the 'paq there, but after a few SETUP packets: <7>udc: SETUP 00.05 v0011 i0000 l0000
Those aren't that common. The hardware is _never_ supposed to be reporting SET_ADDRESS requests, but apparently it's done so forever (no erratum). Intermittently; which might be a factor in why this worked for you before. (None of the recent changes should have affected ep0 handling, or even the PIO paths.)
I wonder if the handling of that misbehavior is causing some
lost synchronization, then more trouble later on. Robert Schwebel
reported a problem in some enumeration testing. I saw some too
for a while -- but they stopped, so I never changed SET_ADDRESS
response logic to jiggle IPR/OPR like SET_{CONFIGURATION,INTERFACE}
now do. That jiggling made a lot of wierdness go away...<7>udc: SETUP 80.06 v0100 i0000 l0008 <7>udc: SETUP 80.06 v0100 i0000 l0012 <7>udc: SETUP 80.06 v0200 i0000 l0008 <7>udc: SETUP 80.06 v0200 i0000 l0020
the UDC decides that ep0in is in a premature status, as follows: <7>udc: ep0in premature status
That's writing two packets; reasonable for a host to only ask for those, and not read the zero length packet like it should. I don't know whether all the Linux HCDs do the same thing there. I usually tested with OHCI; the other codepath might have a problem on PXA.
I am considering making it bang on ep0 until it is ready, assuming I'm not using my rectally-based knowledge (ie, assuming the issue is what I think it is, that we've interrupted and the UDC hasn't gotten the full packet yet.)
PXA hardware seems to have certain "sensitivities" ... ;)
The "premature status" is presumably for that fetch of the config descriptor (80.06/0200) ... and the next request will be automagic, SET_CONFIGURATION. I wouldn't rule out the hardware already having completed handling the set_config processing before the driver noticed anything happened, especially if the host is not actually reading the ZLP.
Minor experiment: Pad out that descriptor by tagging another descriptor at the end, maybe a vendor descriptor, less than 16 bytes (maxpacket) long. This can rule out strangeness caused in the "expect to write a ZLP" codepaths. Leaving, I'd hope, only strangeness caused by set_address ... and nothing else!
However: I _have_ been getting half-packets (16 out of 18 bytes), so I will have to look into that.
Well, ep0 maxpacket is 16 bytes, so that's just the first of two packets. Looks like a device descriptor fetch, immediately after set_address ...
- Dave
/j
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
