On Thu, 9 Jul 2009, Steve Calfee wrote: > Your patch is wrong Yes it is. At the very least it contains a logic error (the "err < 4" test will always encompass "err < 0" and "err == -ENODATA"). > and maybe so is the current code, I haven't looked. > > 1) String descriptors are optional, a device does not have to have any. > > b) When a device cannot handle a control command, it will return a STALL pid. > > iii) When windows xp enumerates a gadget and it gets a stall on the > string desc "0" fetch, it stops fetching device strings. Since most > gadgets are only tested under windows, if you then request a string > after it has told you there are no strings, some gadgets will hang. > > I believe that the proper response after getting a STALL from a fetch > of string desc 0, the system should flag the device as not having > strings and fail all future requests with a STALL (EPIPE) - without > going out on the bus. I am working with a quite old kernel and cannot > provide a patch to the latest kernel to try this. That's close to what the kernel used to do before Daniel's change was made. Instead of flagging the device we simply failed the fetch. Then further attempts to retrieve string descriptors would go through the same procedure and fail in the same way. It wouldn't be hard to flag the device so that the further attempts could be cut short. The problem is that Daniel's device doesn't seem to fit this model. However I don't recall seeing any usbmon logs for it. Daniel, can you show us exactly how your device behaves? Alan Stern -- 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
