linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc C <marc.ceeeee@gmail.com>
To: linux-ide@vger.kernel.org
Subject: Re: [PATCH v3 1/3] libata: Populate host-to-device FIS "auxiliary" field
Date: Fri, 09 Aug 2013 19:06:35 -0700	[thread overview]
Message-ID: <5205A02B.6010208@gmail.com> (raw)
In-Reply-To: <52059FBF.7050303@gmail.com>


Hello,
> The auxiliary field is part of ata taskfile for all intents and purposes.
> FIS is the new command structure anyway and struct ata_taskfile proper
> should be able to describe the command with ata_queuedcmd providing
> the surrounding context.  The argument that ata_taskfile shouldn't
> contain anything which wasn't in PATA taskfile is bogus as it already
> contains ATA_TFLAG_*.
>     That's what make 'struct ata_taskfile' bogus. I'm going to remove 
> 'protocol', 'flags', and 'ctl' fields from there (at least to save a space in 
> 'struct ata_queued_cmd' because they're not used in 'result_tf').
>
>> So, please put the aux field into ata_taskfile.  That's where it
>> belongs.
>     Can't agree to that. I was going to make 'struct ata_taskfile' reflect the 
> historical notion and remove from it all not belonging to that notion. Alas, 
> libata has a bad history of mistreating the historical terms...

While I understand that some non-spec items don't belong in the taskfile struct (and should/will be cleaned up), I have to agree with Tejun regarding how the auxiliary field should be put in 'struct ata_taskfile'. If anything, the struct should represent ALL items that an ATA command will use as inputs. As of now, it's the stuff that's currently in the taskfile + this pesky new 'auxiliary' entry. (FYI, ATA-8 ACS refers to these items as"fields.")

>From what I can tell, there are a couple of places where a rigid definition of a taskfile truly matters, and that's:

1) SCSI to ATA passthrough
2) PATA

But in any event, sticking 'auxiliary' in doesn't matter from a compatibility standpoint, since only NCQ commands use the new field, and the above can't transport NCQ (yet in (1) case).

Tejun put it succinctly by stating:

> I mean, FIS is the new TF.  We can rename ata_taskfile to
> ata_fis and map things the other way but that'd just be extra churn.

Ideally this would be the case, since the SATA FIS is a super-set of any/all fields defined in all ATA commands.

Regards,
Marc




       reply	other threads:[~2013-08-10  2:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <52059FBF.7050303@gmail.com>
2013-08-10  2:06 ` Marc C [this message]
2013-08-09  4:49 [PATCH v3 0/3] Introduce new SATA queued commands Marc C
2013-08-09  4:49 ` [PATCH v3 1/3] libata: Populate host-to-device FIS "auxiliary" field Marc C
2013-08-09 14:03   ` Tejun Heo
2013-08-09 14:36     ` Sergei Shtylyov
2013-08-09 14:53       ` Tejun Heo
2013-08-09 21:39         ` Sergei Shtylyov
2013-08-09 21:51           ` Tejun Heo
2013-08-09 22:17             ` Sergei Shtylyov
2013-08-09 22:26               ` Tejun Heo
2013-08-10 21:59                 ` Sergei Shtylyov
2013-08-12 13:58                   ` Tejun Heo
2013-08-09 21:24     ` Sergei Shtylyov
2013-08-09 14:17   ` Sergei Shtylyov
2013-08-09 14:29     ` Sergei Shtylyov
2013-08-09 14:26   ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5205A02B.6010208@gmail.com \
    --to=marc.ceeeee@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).