On Thu, Oct 13, 2011 at 6:01 PM, Chris Friesen <chris.friesen@xxxxxxxxxxx> wrote: > On 10/13/2011 09:19 AM, Markus Rechberger wrote: >> >> On Thu, Oct 13, 2011 at 4:58 PM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> >> wrote: > >>> This is very interesting. There are only two things that could be >>> happening: Either the device sends different data during the two tests, >>> or there's a bug in the kernel. > >> Before that I insist that this patch will go into the kernel (I know >> that sounds ridiculous but so far I did everything >> you requested me to do), I clearly pointed out that we even have hardware >> specs which can influence the transfer buffer. The patch does not hurt >> and makes the device work. > > That makes no sense. If there's a bug in the hardware we likely don't want > to make global changes to work around it--a more targeted fix may be more > appropriate. > Did you read the part about that we have some hardware which can do some settings in hardware to affect the transfer buffer? Even that part is not clear how it can affect the transfer for the usb subsystem. Why on earth should things be done differently than with all other operating systems? > If there is a bug in the kernel, why would we want a bandaid patch that just > happens to make it work rather than a true fix? > In silicon? Are you going to tape out another one for it? First priority is that the device can work and be sold, my last priority is that requested academic research (as we are not the design house for the particular IC), I'm willing to support it if my request is fulfilled, the demo videos are online and show that it works with increasing the maximum allowed buffersize. And about the particular device the boundaries are just around 7000 bytes off and people are screaming about that? Sorry this is just like in kindergarden here. Markus -- 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
