32-bit IO to-do item...
Alan,
I keep meaning to mention this (and get it into the mail archive)... The 32-bit IO patch was incomplete, because it rendered ATA_IOC_[GS]ET_IO32 handling in ata_sas_scsi_ioctl() -- our base ioctl handler -- incorrect.
Previously, it simply ensured the ioctls reflected hardcoded 16-bit I/O.
Now, behavior no longer matches what the ioctls report.
At a minimum, drivers probably need to set an "I'm using 32bit I/O" flag, that the ioctl then reads, replacing ata_sas_scsi_ioctl()'s assumption that val==0.
Jeff
Quoted 7 lines · On Thu, 09 Apr 2009 01:25:40 -0400 Jeff Garzik <[email protected]> wrote:
Alan,
I keep meaning to mention this (and get it into the mail archive)... The 32-bit IO patch was incomplete, because it rendered ATA_IOC_[GS]ET_IO32 handling in
ata_sas_scsi_ioctl()-- our base ioctl handler -- incorrect.
Quoted 6 lines
Previously, it simply ensured the ioctls reflected hardcoded 16-bit I/O.
Now, behavior no longer matches what the ioctls report.At a minimum, drivers probably need to set an "I'm using 32bit I/O" flag, that the ioctl then reads, replacing ata_sas_scsi_ioctl()'s assumption that val==0.
Put onto my TODO list. I missed the fact you were even faking that rather bogus ioctl (what for example does a PIO over DMA device claim ??)
Quoted 7 lines · Alan Cox
Quoted 4 lines · On Thu, 09 Apr 2009 01:25:40 -0400 Jeff Garzik <[email protected]> wrote:
Alan,
I keep meaning to mention this (and get it into the mail archive)... The 32-bit IO patch was incomplete, because it rendered ATA_IOC_[GS]ET_IO32 handling in
ata_sas_scsi_ioctl()-- our base ioctl handler -- incorrect.
Quoted 7 lines
Quoted 4 lines
Previously, it simply ensured the ioctls reflected hardcoded 16-bit I/O.
Now, behavior no longer matches what the ioctls report.At a minimum, drivers probably need to set an "I'm using 32bit I/O" flag, that the ioctl then reads, replacing ata_sas_scsi_ioctl()'s assumption that val==0.
Put onto my TODO list. I missed the fact you were even faking that rather bogus ioctl (what for example does a PIO over DMA device claim ??)
Probably as a result of a questionable choice to create new named constants ATA_IOC_* as a replacement for existing constants HDIO_* I did that to avoid including linux/hdreg.h -- something we quickly wound up doing anyway.
I'd say pio-over-dma returns '1', so as to imply '0' meaning boring, slow, legacy compatible 16-bit I/O. But it's a good question....
Jeff
Quoted 2 lines
I'd say pio-over-dma returns '1', so as to imply '0' meaning boring, slow, legacy compatible 16-bit I/O. But it's a good question....
And 8bit transfers ?
The more I look at this the more I think we should just admit it was a dumb interface and do something different. To start with do we mean the controller-disk transfer is 32bit (meaningful only in some early proto IDE stuff), or the controller-fifo transfer is 32bit (which is meaningless as actually its posted)
Quoted 9 lines · Alan Cox
Quoted 1 line
I'd say pio-over-dma returns '1', so as to imply '0' meaning boring, slow, legacy compatible 16-bit I/O. But it's a good question....
And 8bit transfers ?
The more I look at this the more I think we should just admit it was a dumb interface and do something different. To start with do we mean the controller-disk transfer is 32bit (meaningful only in some early proto IDE stuff), or the controller-fifo transfer is 32bit (which is meaningless as actually its posted)
Sure it's a dumb interface, it's a legacy ioctl... :) We do the best we can with a legacy interface.
On a more general level, sure, libata sorely lacks a control interface for twiddling host controller features, or even device xfer modes.
Jeff