On Thu, Jul 08, 2004 at 01:52:51PM -0400, Alan Stern wrote: > 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?
I think, for now, since this seems to be the only device which is so badly
broken, let's just leave it as a hard-coded thing. That is, check for the
Genesys vendorID in both places (max_sectors and delay).
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
Why am I talking to a toilet brush?
-- CEO
User Friendly, 4/30/1998
pgprngo1hDReS.pgp
Description: PGP signature
