On Thu, 8 Jul 2004, Matthew Dharm wrote: > I'm seriously tempted not to mess with this. We have the 'official answer' > from the vendor -- lord knows if there is some sort of race condition which > is less common (but could occur) between 64 and 120.
All right. The actual comment from the support person was "to solve 811 DMA can't over 64K issues" -- I take that to mean you can't transfer more than 64 KB per command. Maybe he recommended making the maximum size 32 KB because he thought it had to be a power of 2, maybe he had some stronger reason, or maybe he thought the sector size was 1024 rather than 512. (I should try asking; who knows, they might even answer...) > Let's just take the 'official' number and be done with it. Maybe include a > comment that says "it might work with a larger number -- go tune it at > runtime via sysfs if you want". Okay. This leaves another matter or two to settle. Right now the code checks specifically for a Genesys vendorID while running at high speed before reducing max_sectors. Should we make that more general, perhaps adding an unusual_devs flag? If so, should we have one flag for 32 KB and another for 64 KB? Also there's that 100 usec delay. Clearly we don't want to invoke it for every device. Should that be yet another unusual_devs flag? What if we run across some other device that needs a 200 usec delay? Make it accessible via sysfs, like max_sectors? Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
