32-bit IO to-do item...

32-bit IO to-do item...

[Jeff Garzik]

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

Re: 32-bit IO to-do item...

[Alan Cox]

On Thu, 09 Apr 2009 01:25:40 -0400
Jeff Garzik <jeff@garzik.org> 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.
> 
> 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 ??)

Re: 32-bit IO to-do item...

[Jeff Garzik]

Alan Cox wrote:
> On Thu, 09 Apr 2009 01:25:40 -0400
> Jeff Garzik <jeff@garzik.org> 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.
>>
>> 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

Re: 32-bit IO to-do item...

[Alan Cox]

> 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)

Re: 32-bit IO to-do item...

[Jeff Garzik]

Alan Cox wrote:
>> 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