Hi, On Wed, Nov 05, 2008 at 02:54:44PM +0300, Sergei Shtylyov wrote: > Phil Sutter wrote: > > >Well, Sergei Shtylyov pointed out that the original driver does transfer > >data at 4-byte blocks, so I changed it accordingly and tested it. > >Hopefully this will provide a performance gain, though I did not do any > >performance tests and therefore can't tell if that's really the case. > > > > Might've been worth to put this into separate patch, apart from the > fix for the function prototype. Ok, I will do that. > >I had interpreted Sergei's response to my BUG_ON() statement for it to > >be unnecessary, which may be wrong. > > You misintepreted my response. :-) Oh well, if only communication was as easy as programming C. :) > >I don't know if it's possible to > >connect ATAPI devices to the on board CompactFlash slot, maybe you can > > I don't think so. What about those devices for PDAs like GPS mice or UMTS modems? The platform for dangerous half knowledge talks about "CF I/O". Is this something completely different? > >give me some hints on this. OTOH I see that the sector size is hard > >coded in the original driver to 0x200, so I guess either ATAPI is not > >possible or at least not with the original driver, right? > > If ATAPI was indeed possible, BUG() wouldn't have been an option. > I've just remembered about the READ/WRITE LONG commands which might > cause byte count to not be divisible by 4 (although by default ECC is > 4-byte entity and CF 1.4 says that this is the ony option). Sure, I added it because it's an assumption made on the algorithm to function correctly and I wasn't sure if that's the case. So what's the final solution to this? Transfer byte-wise if buflen is not a multiple of four (I doubt this would provide full ATAPI compatibility, though I have no idea) or maybe transfer (buflen % 4) bytes less and return something different than buflen? I sadly don't have any hardware to test with other than a CF-disk, which of course is an ATA device. Thanks, Phil -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
