hdregs.h puts csfo at word 129 - wrong, that's vendor specific

hdregs.h puts csfo at word 129 - wrong, that's vendor specific

[Chris Hann]

ide-disk.c checks csfo bit 0 to see if the cache is available on a device
hdregs.h maps csfo to word 129 of the Identify Device information
the latest ATA documentation, e00159r3 Mandatory IDENTIFY DEVICE 
information, says words 129-159 are Vendor specific.

Why is the driver switching on cache operations based on a word that has 
nothing to do with cache?

My previous attempt was obviously too long?

Chris

Re: hdregs.h puts csfo at word 129 - wrong, that's vendor specific

[Jeff Garzik]

Chris Hann wrote:
> ide-disk.c checks csfo bit 0 to see if the cache is available on a device
> hdregs.h maps csfo to word 129 of the Identify Device information
> the latest ATA documentation, e00159r3 Mandatory IDENTIFY DEVICE 
> information, says words 129-159 are Vendor specific.
> 
> Why is the driver switching on cache operations based on a word that has 
> nothing to do with cache?

Good question...  I would guess that it's some pre-ATA4 legacy magic, 
but that's just a guess.

	Jeff

Re: hdregs.h puts csfo at word 129 - wrong, that's vendor specific

[Brett Russ]

Jeff Garzik wrote:
> Chris Hann wrote:
>> ide-disk.c checks csfo bit 0 to see if the cache is available on a device
>> hdregs.h maps csfo to word 129 of the Identify Device information
>> the latest ATA documentation, e00159r3 Mandatory IDENTIFY DEVICE 
>> information, says words 129-159 are Vendor specific.
>>
>> Why is the driver switching on cache operations based on a word that 
>> has nothing to do with cache?
> 
> 
> Good question...  I would guess that it's some pre-ATA4 legacy magic, 
> but that's just a guess.

I just checked the specs for ATA[134567] (didn't have 2) and all of them 
show word 129 as vendor specific, as Chris found.

The code that's in libata-dev shows in idedisk_setup():

         /* write cache enabled? */
         if ((id->csfo & 1) || (id->cfs_enable_1 & (1 << 5)))
                 drive->wcache = 1;


Bart, what's the point of the csfo bit check?  If it's specific to one 
non-ATA compliant device shouldn't it be testing something else along 
with that bit?

BR

Re: hdregs.h puts csfo at word 129 - wrong, that's vendor specific

[Bartlomiej Zolnierkiewicz]

On Fri, 25 Mar 2005 20:48:21 -0500, Brett Russ <russb@emc.com> wrote:
> Jeff Garzik wrote:
> > Chris Hann wrote:
> >> ide-disk.c checks csfo bit 0 to see if the cache is available on a device
> >> hdregs.h maps csfo to word 129 of the Identify Device information
> >> the latest ATA documentation, e00159r3 Mandatory IDENTIFY DEVICE
> >> information, says words 129-159 are Vendor specific.
> >>
> >> Why is the driver switching on cache operations based on a word that
> >> has nothing to do with cache?
> >
> >
> > Good question...  I would guess that it's some pre-ATA4 legacy magic,
> > but that's just a guess.
> 
> I just checked the specs for ATA[134567] (didn't have 2) and all of them
> show word 129 as vendor specific, as Chris found.
> 
> The code that's in libata-dev shows in idedisk_setup():
> 
>          /* write cache enabled? */
>          if ((id->csfo & 1) || (id->cfs_enable_1 & (1 << 5)))
>                  drive->wcache = 1;
> 
> Bart, what's the point of the csfo bit check?  If it's specific to one
> non-ATA compliant device shouldn't it be testing something else along
> with that bit?

AFAIR it was Alan who added this code, so lets ask him :)

Alan?

Re: hdregs.h puts csfo at word 129 - wrong, that's vendor specific

[Alan Cox]

> AFAIR it was Alan who added this code, so lets ask him :)


The cfso check goes back to Andre

Re: hdregs.h puts csfo at word 129 - wrong, that's vendor specific

[Brett Russ]

This appears to have been dropped.  The last word 
(http://article.gmane.org/gmane.linux.ide/3588) was from Alan who said 
Andre would know the history.

Andre, can you help answer?

Thanks
BR

Brett Russ wrote:
> Jeff Garzik wrote:
> 
>> Chris Hann wrote:
>>
>>> ide-disk.c checks csfo bit 0 to see if the cache is available on a 
>>> device
>>> hdregs.h maps csfo to word 129 of the Identify Device information
>>> the latest ATA documentation, e00159r3 Mandatory IDENTIFY DEVICE 
>>> information, says words 129-159 are Vendor specific.
>>>
>>> Why is the driver switching on cache operations based on a word that 
>>> has nothing to do with cache?
>>
>>
>>
>> Good question...  I would guess that it's some pre-ATA4 legacy magic, 
>> but that's just a guess.
> 
> 
> I just checked the specs for ATA[134567] (didn't have 2) and all of them 
> show word 129 as vendor specific, as Chris found.
> 
> The code that's in libata-dev shows in idedisk_setup():
> 
>         /* write cache enabled? */
>         if ((id->csfo & 1) || (id->cfs_enable_1 & (1 << 5)))
>                 drive->wcache = 1;
> 
> 
> Bart, what's the point of the csfo bit check?  If it's specific to one 
> non-ATA compliant device shouldn't it be testing something else along 
> with that bit?
> 
> BR
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html