Re: [RFC] libata IORDY handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

Alan wrote:

I looked into fixing this but had a feeling that the thing wasn't right from the very start, including ata_pio_need_iordy(). In my understanding of the ANSI T13 stadrads, when one issues Set Features subcommand Set Transfer Mode with sector count register of 0x8 thru 0xC this means that IORDY *must* be enabled.

Yes. It is more complex than the current code handles. That's one reason
I added ata_pio_need_iordy(), because it would need to change and

I also meant this function: if IORDY *must* be enabled even for PIO mode 0 (being set the way liabata sets it, via the mentioned subcommand), what's the point of checking if we need to enable IORDY? The only reason for this function as it seems is to check if we can do *without* IORDY still... Even if so, we must check if any of these both drives need IORDY to decide whether we need to enable IORDY checking on taskfile accesses or not -- which this function fails to do...

hardcoding it would be particularly ugly.

Yeah, hardcoding is ugly, no doubt about it. This is still a problem with both pdc202xx_new and pata_pdc2027x, for example...

This will matter for supporting some utterly ancient junk.

   Well, SiI680 seemed to me quite well designed. :-)

Alan

MBR, Sergei
-
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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux